arm64: dts: qcom: glymur: Add missing USB clock, power and bandwidth votes

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 <[email protected]>

---
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?

Quoted 36 lines · Greg Ociepka

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.

Quoted 8 lines

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 <[email protected]>

This looks OK to me.

Reviewed-by Abel Vesa <[email protected]>

Quoted 7 lines

---
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.

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:

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

[...]