Re: [PATCH 05/10] ARM: dts: qcom: msm8960: add RPM clock controller and fix USB clocks

[Konrad Dybcio]

On 4/13/26 8:55 PM, Antony Kurniawan Soemardi via B4 Relay wrote:
> From: Antony Kurniawan Soemardi <linux@xxxxxxxxxxxxxx>
> 
> 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 <linux@xxxxxxxxxxxxxx>
> ---
>  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