Re: [PATCH] arm64: dts: qcom: glymur: Add missing USB clock, power and bandwidth votes

[Krishna Kurapati]

On 8/12/2026 3:53 PM, Abel Vesa wrote:
> On 26-08-12 10:35:22, Greg Ociepka wrote:
> > The four USB3 controller nodes on Glymur (usb_0, usb_1, usb_2, usb_mp)
> > are missing three property groups that Glymur's own usb_hs node at
> > a200000 already carries, and that Hamoa (x1e80100) carries on all five
> > of its USB controllers:
> >
> >    - assigned-clocks / assigned-clock-rates
> >    - required-opps
> >    - interconnects / interconnect-names
> >
> > Without required-opps the controllers place no performance state vote
> > on their power domain. Measured on an Asus Zenbook A16 (UX3607OA) with
> > a SuperSpeed device enumerated, CX aggregates to SVS while the
> > controllers run their master clock at 200 MHz:
> >
> >    $ grep -E "^cx " /sys/kernel/debug/pm_genpd/pm_genpd_summary
> >    cx    on    128
> >
> >    $ grep "usb30.*master_clk " /sys/kernel/debug/clk/clk_summary
> >    gcc_usb30_sec_master_clk   ...  200000000
> >    gcc_usb30_prim_master_clk  ...  200000000
> >    gcc_usb30_mp_master_clk    ...  200000000
> >
> > 128 is RPMH_REGULATOR_LEVEL_SVS; rpmhpd_opp_nom is 256. With this
> > patch applied the same measurement reads 256 while a controller is
> > active.
> >
> > Without interconnects, dwc3_qcom_interconnect_init() silently does
> > nothing: of_icc_get() returns NULL rather than an error pointer for a
> > device without the property, so probe succeeds and icc_set_bw() on a
> > NULL path is a no-op. No USB-DDR bandwidth is ever requested.
> >
> > Without assigned-clock-rates nothing programs the master clock RCG,
> > which keeps whatever the bootloader left behind. On this machine that
> > happens to be the correct 200 MHz, but ftbl_gcc_usb30_mp_master_clk_src
> > also allows 66.67 and 133.33 MHz, neither of which sustains SuperSpeed.
> >
> > Add all three groups to the four nodes, mirroring usb_hs. The
> > interconnect paths follow the provider layout in
> > drivers/interconnect/qcom/glymur.c: usb_0/usb_1 sit on aggre4_noc,
> > usb_mp on aggre3_noc and usb_2 on aggre2_noc.
> >
> > Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
> > Assisted-by: Claude:fable-5
> > Signed-off-by: Greg Ociepka <greg@xxxxxxxxxxxxx>
>
> This looks OK to me.
>
> Reviewed-by: Abel Vesa <abel.vesa@xxxxxxxxxxxxxxxx>
>
> > ---
> > Note for reviewers: Hamoa additionally marks all five USB controllers
> > dma-coherent, while Glymur marks no peripheral DMA master as coherent
> > (only the SMMUs, PCIe controllers and remoteprocs). That difference is
> > deliberately not touched here since getting it wrong is a silent
> > data-corruption class of bug, but it looks like part of the same
> > omission. Is USB DMA coherent on Glymur?
>
> I think so, but lets see what Wesley thinks.
It is dma-coherent.

Regards,
Krishna,