Document the snps,ref-clock-period property that describes reference
clock period when it deviates from the default set value.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -252,6 +252,15 @@ properties:minimum:0maximum:0x3f+snps,ref-clock-period:+description:+Value for REFCLKPER field of GUCTL register for post-silicon reference+clock period in nanoseconds, when the hardware set default does not match+the actual clock.+$ref:/schemas/types.yaml#/definitions/uint32+minimum:1+maximum:0x3ff+snps,rx-thr-num-pkt-prd:description:Periodic ESS RX packet threshold count (host mode only). Set this and
--
2.30.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -386,6 +386,10 @@#define DWC3_GFLADJ_30MHZ_SDBND_SEL BIT(7)#define DWC3_GFLADJ_30MHZ_MASK 0x3f+/* Global User Control Register*/+#define DWC3_GUCTL_REFCLKPER_MASK 0xffc00000+#define DWC3_GUCTL_REFCLKPER_SEL 22+/* Global User Control Register 2 */#define DWC3_GUCTL2_RST_ACTBITLATER BIT(14)
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
--
balbi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
Thinh Nguyen asked to add a dedicated DT property. He explained that
clk_get_rate() does not work for PCI hosted dwc3. This is the most
complete summary of the discussion:
Hence the "optional" :-)
Or, perhaps, Thinh wants to use this for internal FPGA-based validation?
In that case, I'm okay with the property.
--
balbi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
Thinh Nguyen asked to add a dedicated DT property. He explained that
clk_get_rate() does not work for PCI hosted dwc3. This is the most
complete summary of the discussion:
Hence the "optional" :-)
Or, perhaps, Thinh wants to use this for internal FPGA-based validation?
In that case, I'm okay with the property.
We do use it for internal FPGA validation, but it should help for other
dwc3 PCI devices also.
BR,
Thinh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-08-13 17:22:38
On Wed, Aug 04, 2021 at 05:05:07PM +0300, Baruch Siach wrote:
quoted hunk
Document the snps,ref-clock-period property that describes reference
clock period when it deviates from the default set value.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
Documentation/devicetree/bindings/usb/snps,dwc3.yaml | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -252,6 +252,15 @@ properties:minimum:0maximum:0x3f+snps,ref-clock-period:+description:+Value for REFCLKPER field of GUCTL register for post-silicon reference
Why is post-silicon relevant here? Everything upstream should be for
post-silicon. I've seen and done the hacks to make pre-silicon testing
work and we don't need those upstream.
+ clock period in nanoseconds, when the hardware set default does not match
If you have units, then use property unit suffix in the name.
+ the actual clock.
+ $ref: /schemas/types.yaml#/definitions/uint32
And then you can drop the type.
However, if the h/w block gets a ref clock why isn't it described in
'clocks' and then you can just read why the frequency is and calculate
the period.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
PCI devices can have DT nodes with clock properties too. Or use the
VID/PID to infer the frequency. Or use 'clock-frequency' property.
It boils down to we have lots of standard properties for clocks and
clock configuration, so custom properties are a NAK.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
I wonder if it would make more sense to pass an actual clock reference
here. If valid, then reconfigure the period to the value returned by
clk_get_rate(). It would avoid yet another DT binding. If we make the
clock optional, then we won't affect any other platforms. The clock
itself could be a regular fixed clock node.
PCI devices can have DT nodes with clock properties too. Or use the
VID/PID to infer the frequency. Or use 'clock-frequency' property.
It boils down to we have lots of standard properties for clocks and
clock configuration, so custom properties are a NAK.
Do we have DT node for the PCI device before discovering the device from
PCI bus enumeration? I don't think we can find the clock properties from
its configuration space. For our HAPS devices, we can't use VID/PID to
infer the frequency since our phy and ref clock may change.
Does "clock-frequency" mean ref clock? If so, let's use that?
Thanks,
Thinh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel