| Message ID | 3d86f45004fe2fcbae0a2cd197df81a1fd076a1e.1628085910.git.baruch@tkos.co.il |
|---|---|
| State | Accepted |
| Commit | 2433ab638f10b6ca94416df501bc8cb24589c6a8 |
| Headers | show |
| Series | [v2,1/6] dt-bindings: phy: qcom,qmp: Add IPQ6018 USB3 PHY | expand |
Hi, Baruch Siach <baruch@tkos.co.il> writes: > @@ -1371,6 +1398,8 @@ static void dwc3_get_properties(struct dwc3 *dwc) > &dwc->hsphy_interface); > device_property_read_u32(dev, "snps,quirk-frame-length-adjustment", > &dwc->fladj); > + device_property_read_u32(dev, "snps,ref-clock-period", > + &dwc->ref_clk_per); 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.
Hi, Baruch Siach <baruch@tkos.co.il> writes: > Hi Felipe, > > On Wed, Aug 04 2021, Felipe Balbi wrote: >> Baruch Siach <baruch@tkos.co.il> writes: >>> @@ -1371,6 +1398,8 @@ static void dwc3_get_properties(struct dwc3 *dwc) >>> &dwc->hsphy_interface); >>> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment", >>> &dwc->fladj); >>> + device_property_read_u32(dev, "snps,ref-clock-period", >>> + &dwc->ref_clk_per); >> >> 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.
On 04-08-21, 17:05, Baruch Siach wrote:
> Add compatible string for USB3 PHY in Qualcomm IPQ6018 SoC.
Applied, thanks
Felipe Balbi wrote: > > Hi, > > Baruch Siach <baruch@tkos.co.il> writes: >> Hi Felipe, >> >> On Wed, Aug 04 2021, Felipe Balbi wrote: >>> Baruch Siach <baruch@tkos.co.il> writes: >>>> @@ -1371,6 +1398,8 @@ static void dwc3_get_properties(struct dwc3 *dwc) >>>> &dwc->hsphy_interface); >>>> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment", >>>> &dwc->fladj); >>>> + device_property_read_u32(dev, "snps,ref-clock-period", >>>> + &dwc->ref_clk_per); >>> >>> 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
Rob Herring wrote: > On Wed, Aug 04, 2021 at 05:22:27PM +0300, Baruch Siach wrote: >> Hi Felipe, >> >> On Wed, Aug 04 2021, Felipe Balbi wrote: >>> Baruch Siach <baruch@tkos.co.il> writes: >>>> @@ -1371,6 +1398,8 @@ static void dwc3_get_properties(struct dwc3 *dwc) >>>> &dwc->hsphy_interface); >>>> device_property_read_u32(dev, "snps,quirk-frame-length-adjustment", >>>> &dwc->fladj); >>>> + device_property_read_u32(dev, "snps,ref-clock-period", >>>> + &dwc->ref_clk_per); >>> >>> 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://urldefense.com/v3/__https://lore.kernel.org/r/c797e9cb-cae6-c0b6-5714-169c2ad79d32@synopsys.com__;!!A4F2R9G_pg!Nh6rqp_aOd8XIvqELvDRQe5ooZf13UZKwmn9lWcRgdbyMKpTMzL8HasrB1X2Ojvumo8g$ > > 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
diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f0497b8623ad..3ae865988f04 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy
Add compatible string for USB3 PHY in Qualcomm IPQ6018 SoC. Signed-off-by: Baruch Siach <baruch@tkos.co.il> --- Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml | 1 + 1 file changed, 1 insertion(+)