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
@@ -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
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:
https://lore.kernel.org/r/c797e9cb-cae6-c0b6-5714-169c2ad79d32@synopsys.com
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
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
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
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.
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
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