On 6/1/26 10:51 AM, 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]>
> ---
> @@ -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?
Konrad
