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?

Konrad

Reply via email to