On Wed, Apr 15, 2026 at 11:28:40AM +0200, Konrad Dybcio wrote: > On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote: > > From: Antony Kurniawan Soemardi <[email protected]> > > > > The RPM clock controller manages clocks shared between the application > > processor and the RPM firmware, including fabric and bus clocks required > > by several peripherals. > > > > With the RPM clock controller now available in the device tree, the USB > > controller must explicitly declare its dependency on > > RPM_DAYTONA_FABRIC_CLK. Without this declaration, the clock framework > > would consider it unused and disable it, breaking USB functionality. > > > > This also corrects the previous misuse of USB_HS1_XCVR_CLK as the core > > clock. The XCVR clock is in fact used for PHY/reset handling rather than > > as the main core clock. > > > > A similar issue has been observed on APQ8064, where missing the RPM > > fabric clock dependency leads to broken USB. > > > > Signed-off-by: Antony Kurniawan Soemardi <[email protected]> > > --- > > arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 16 ++++++++++++++-- > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi > > b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi > > index fd28401cebb5..1d5e97b6aa4b 100644 > > --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi > > +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi > > @@ -5,6 +5,7 @@ > > #include <dt-bindings/clock/qcom,gcc-msm8960.h> > > #include <dt-bindings/reset/qcom,gcc-msm8960.h> > > #include <dt-bindings/clock/qcom,lcc-msm8960.h> > > +#include <dt-bindings/clock/qcom,rpmcc.h> > > #include <dt-bindings/mfd/qcom-rpm.h> > > #include <dt-bindings/soc/qcom,gsbi.h> > > > > @@ -98,6 +99,13 @@ rpm: rpm@108000 { > > interrupt-names = "ack", > > "err", > > "wakeup"; > > + > > + rpmcc: clock-controller { > > + compatible = "qcom,rpmcc-msm8960", "qcom,rpmcc"; > > + #clock-cells = <1>; > > + clocks = <&pxo_board>, <&cxo_board>; > > + clock-names = "pxo", "cxo"; > > nit: one a line would be preferred > > > + }; > > }; > > > > ssbi: ssbi@500000 { > > @@ -507,8 +515,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 = <&rpmcc RPM_DAYTONA_FABRIC_CLK>, > > I still have mixed feelings whether this should be a clock or an > interconnect resource.. > > Some internal data tells me this is used by: > > * USB > * SDCC > * GSBI > * INTC > * APSS? > * BAM DMA > > or anything that is adjacent to SPS. I think any/all clients vote either > zero/off or 64 MHz, on MSM8960. It seems to be an IP that wasn't really > used for a long time (and a long time ago, at that), so it's difficult to > judge. > > I see that the list above is roughy in line with where msm-3.x attaches > the votes (also for QSEECOM and friends).. > > +Dmitry, would you know more?
As per my understadning, those chips had several fixed-speed buses. So, you are right, these are interconnects, but they are not scalable. When it comes to such buses (AHB, AXI), we quite frequently model them as clocks rather than interconnects. For example the same ChipIdea USB core on MSM8916 or MSM8974 uses "iface" clock for the GCC_USB_HS_AHB_CLK. -- With best wishes Dmitry
