Re: [PATCH v3 05/10] ARM: dts: qcom: msm8960: add RPM clock controller and fix USB clocks
Antony Kurniawan Soemardi <[email protected]>
| Newsgroups | org.kernel.vger.phone-devel,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 6/9/2026 7:21 PM, Konrad Dybcio wrote: > On 6/1/26 10:51 AM, Antony Kurniawan Soemardi via B4 Relay wrote: >> From: Antony Kurniawan Soemardi <[email protected]> >> @@ -507,8 +519,12 @@ usb1: usb@12500000 { >> reg = <0x12500000 0x200>, >> <0x12500200 0x200>; >> interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>; >> - clocks = <&gcc USB_HS1_XCVR_CLK>, <&gcc USB_HS1_H_CLK>; >> - clock-names = "core", "iface"; >> + clocks = <&gcc USB_HS1_H_CLK>, >> + <&rpmcc RPM_DAYTONA_FABRIC_CLK>, >> + <&gcc USB_HS1_XCVR_CLK>; >> + clock-names = "iface", >> + "core", >> + "fs"; > > The bindings change you sent changes the expectations - "core" used > to be the first clock. And I would guesstimate that the > DAYTONA_FABRIC clock is not really "core" - does downstream do any > ratesetting on the other two? Looking at the downstream, I can only find HS1_XCVR being set to 60MHz, DAYTONA_FABRIC being set to the max rate (just for voting purposes?). I don't see any clk_set_rate for HS1_P though. Would you rather the other way around? Like "core", "iface", and "fs"? My concern is that such a change would result in a large number of warnings for newer SoC device trees. -- Thanks, Antony K. S.