From: Lloyd Hazlett <[email protected]>
> Does this *actually* cause any harm, by the way?
>
> For example on x1e, GMU refers to 2 GPU_CC GDSCs, GPU_CC refers
> to a pair of GCC clocks and GCC refers to VDD_CX
>
> and I see these prints, yet:
>
> /sys/kernel/debug/pm_genpd/gpu_cx_gdsc/current_state:off-0
> /sys/kernel/debug/pm_genpd/gpu_gx_gdsc/current_state:off-0
I may well be missing something, but on an ASUS Zenbook A14 (x1e80100,
next-20261001) the GCC half of that message does seem to cost
something. The GPU_CC domains here are off as you describe; it is the
GCC ones that stay on.
Every GDSC the firmware hands over enabled is registered powered-on,
genpd records that as stay_on, and genpd_power_off() returns on that
flag before it looks at consumers. So nothing downstream can release
them. Unbinding dwc3-qcom, runtime-suspending the controllers and
booting without pd_ignore_unused each made no difference.
UFS is the clearest case: ufshc@1d84000 is status = "disabled" with no
driver bound, and gcc_ufs_phy_gdsc and gcc_ufs_mem_phy_gdsc still read
"on" through a suspend.
With fw_devlink.sync_state=timeout, seven domains let go - both UFS,
gcc_usb30_tert_gdsc and gcc_usb20_prim_gdsc straight away, and
gcc_usb30_{prim,sec,mp}_gdsc once xhci-hcd and dwc3-qcom are also
allowed to runtime-suspend. Their idle_states show Usage 1, Rejected 0.
Suspend draw on battery, same kernel either side, both windows ~99%
suspended:
domains held on 23.3 Wh / 21.3 h 1.09 W
seven released 2.0 Wh / 2.3 h 0.87 W
The windows are very different lengths, so to be clear about which way
that cuts: the long one is the most reliable figure I have for the
held-on case, and shorter runs of that same configuration came out
higher, between 1.1 and 1.7 W. Taking the lowest of them makes ~20%
the conservative reading. It is not the whole problem, since this
machine never reaches cxsd either way. It may relate to your note in
the same mail that cx sits at perf_state 256 "because of USB3 votes":
those GDSCs cannot collapse, so the votes stay.
The same thing happens here with a second device, in case that is
useful:
qnoc-x1e80100 interconnect-1: sync_state() pending due to 1dfa000.crypto
qnoc-x1e80100 1700000.interconnect: sync_state() pending due to 1dfa000.crypto
1dfa000.crypto is enabled in DT but qce is not built here, so it never
probes. Any consumer that never binds seems to do this to its provider,
so the GMU may be the most visible case rather than the only one.
I have not tested the patch itself - the GMU here has no driver bound,
which is what led me to the thread. This is only evidence that the
motivation holds on x1e80100.
Assisted-by: Claude:claude-opus-5 [claude-code]
