[PATCH] pmdomain: qcom: rpmhpd: don't clamp gfx and gmxc before sync_state

[PATCH] pmdomain: qcom: rpmhpd: don't clamp gfx and gmxc before sync_state

[Oleg Keri]

Until rpmhpd's sync_state every vote is clamped to the highest corner,
so that hardware the bootloader left running keeps the rail level it
needs until its driver takes over.  Nothing the bootloader leaves behind
runs on the GPU rails, but the clamp hits them anyway: the GPU clock
controller's probe runtime-resumes and suspends its GFX and GMXC
domains, and from then on both rails are pinned at their highest corner
until sync_state.

On Glymur gfx.lvl has 14 levels and the clamp holds the rail at the top
one, 0x1d0, while the GMU's own performance table ends at level 11,
0x1c4.  With the GPU driver and firmware built in, the GMU boots long
before sync_state, and its CLX DCVS calibration does not survive a gfx
rail held that high: the firmware gives up with HFI_F2H_MSG_ERROR
0x007306c7 (ResMgrCalibrateDcvsLvl), the first HFI_H2F_MSG_GX_BW_PERF_VOTE
times out and the first GPU init fails.  On the Lenovo Yoga Slim 7x
Gen 11 this means the compositor cannot start at first login.  Pinning
gfx at level 11 or 12 instead fails the same way, level 10 and below
boot fine, and pinning gmxc alone has no effect.

Leave gfx and gmxc out of the clamp: they have no bootloader-configured
consumer to protect, and the GMU votes them through its own RSC.

Fixes: 93b6c8d10fad ("drm/msm/a8xx: Enable CLX feature on Adreno X2-85")
Link: https://lore.kernel.org/r/179248663855.32151.9955864156939592299@gmail.com
Acked-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Signed-off-by: Oleg Keri <okerixx@gmail.com>
---
 drivers/pmdomain/qcom/rpmhpd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index fa8fed5bd3e5..2c9d4beeffbe 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -1006,7 +1006,7 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner)
 	unsigned int peer_active_corner = 0, peer_sleep_corner = 0;
 	unsigned int peer_enabled_corner;
 
-	if (pd->state_synced) {
+	if (pd->state_synced || pd == &gfx || pd == &gmxc) {
 		to_active_sleep(pd, corner, &this_active_corner, &this_sleep_corner);
 	} else {
 		/* Clamp to highest corner if sync_state hasn't happened */

base-commit: 2efb7a11f1aa4d2dc285fe2680cca22cb9f72f64
-- 
2.55.0

Re: [PATCH] pmdomain: qcom: rpmhpd: don't clamp gfx and gmxc before sync_state

[Denis Zornada]

(Resent as plain text, the first copy had an HTML part and bounced off
the lists.)

On Wed, Oct 21, 2026 at 10:05:17AM +0200, Oleg Keri wrote:
> Leave gfx and gmxc out of the clamp: they have no bootloader-configured
> consumer to protect, and the GMU votes them through its own RSC.

Tested on an ASUS Zenbook A16 (UX3607OA, Adreno X2-90, GMU fw v5.2.38)
with next-20261020 and the upstream DTS. Distro-style config: msm is a
module and the firmware is loaded from the initramfs, so this is not
limited to built-in setups.

Without this patch the first GPU init fails as on the other machines,
and every retry fails until fw_devlink forces sync_state:

  [    3.584003] [drm] Loaded GMU firmware v5.2.38
  [    4.641088] platform 3d6c000.gmu: [drm:a6xx_hfi_wait_for_msg_interrupt [msm]] *ERROR* Message HFI_H2F_MSG_GX_BW_PERF_VOTE id 11 timed out waiting for response
  [    4.760713] msm_dpu ae01000.display-controller: [drm:adreno_load_gpu [msm]] *ERROR* gpu hw init failed: -110
  ... (26 more "Couldn't power up the GPU: -110" up to 18.7 s)
  [   19.937852] gpucc-glymur 3d90000.clock-controller: Timed out. Forcing sync_state()

A GPU open after that (~290 s) succeeds, so this machine behaves like
the Yoga, not like Abel's CRD.

With this patch on the same tree the first init succeeds: no
GX_BW_PERF_VOTE timeout after "Loaded GMU firmware" at 3.7 s, the GPU
comes up at probe, long before sync_state (19.4 s), and a small Vulkan
test (vkCmdFillBuffer plus readback) passes on the X2-90. Two boots with
a complete log show this; on a third the log was cut short by an
unrelated reset. On this tree the A16 eDP link fails to train without
additional local display patches, and once a compositor drives the panel
the machine resets, so I ran the GPU test without a compositor.

Tested-by: Denis Zornada <denis_zornada@hotmail.com> # Zenbook A16

Re: [PATCH] pmdomain: qcom: rpmhpd: don't clamp gfx and gmxc before sync_state

[Vladyslav Tymoshchuk]

On Wed, Oct 21, 2026 at 10:05:17AM +0200, Oleg Keri wrote:
> Until rpmhpd's sync_state every vote is clamped to the highest corner,
> so that hardware the bootloader left running keeps the rail level it
> needs until its driver takes over.  Nothing the bootloader leaves behind
> runs on the GPU rails, but the clamp hits them anyway: the GPU clock
> controller's probe runtime-resumes and suspends its GFX and GMXC
> domains, and from then on both rails are pinned at their highest corner
> until sync_state.

SM8750 (Adreno 830) is hit by the same clamp, with a different symptom
and without CLX, which is only enabled on X2-85 and A840 so far. The
first GPU init succeeds, but when the GMU first boots under the clamped
gfx vote, every ACD level runs at half the requested clock until the
next reboot. msm.disable_acd=1 avoids it.

OnePlus Pad 3, v7.3-rc5 plus board patches, msm as a module loaded by
udev about 4 s after boot, GMU firmware 5.1.25. The clock was measured
as drm-cycles-gpu over drm-engine-gpu in the fdinfo of a vkmark process
keeping the GPU busy, at fixed devfreq levels. The four kernels below
differ only in rpmhpd.c, and I alternated between them from boot to
boot. In every boot in the table the first GMU boot came 62-81 ms
before rpmhpd's sync_state:

  devfreq (MHz)            342   660   1050   1100
  without the patch        342   330    525    550   (10 boots)
  with the patch           342   660   1050   1100   (11 boots)
  local test, only gfx
  left out of the clamp    342   660   1050   1100   (5 boots)
  local test, only gmxc
  left out of the clamp    342   330    525    550   (5 boots)

Every value was the same within 1 MHz across the boots. On one boot of
each kernel I also went through all 14 OPPs. With gfx clamped, 525 MHz
and below ran at the requested clock, 607 MHz at 539-558 MHz, and
734 MHz and up at half. With gfx left out of the clamp, all 14 were
within 1 MHz of the requested clock.

In one more boot of the gmxc-only kernel, sync_state came 83 ms before
the first GMU boot, and that boot ran at the full clock. So, as on
Glymur, only gfx matters here, and only if the GMU first boots while
the clamp is still in place.

With vkmark's blur scene at a pinned 1100 MHz on the same boots, this
is 414-421 fps without the patch and 831-866 fps with it.

Tested-by: Vladyslav Tymoshchuk <tvlad744@gmail.com> # SM8750

Re: [PATCH] pmdomain: qcom: rpmhpd: don't clamp gfx and gmxc before sync_state

[Thorsten Leemhuis]

On 10/21/26 10:05, Oleg Keri wrote:
> Until rpmhpd's sync_state every vote is clamped to the highest corner,
> so that hardware the bootloader left running keeps the rail level it
> needs until its driver takes over.  Nothing the bootloader leaves behind
> runs on the GPU rails, but the clamp hits them anyway: the GPU clock
> controller's probe runtime-resumes and suspends its GFX and GMXC
> domains, and from then on both rails are pinned at their highest corner
> until sync_state.

Ulf, Bjorn, FYI: this is a fix for a regression that was reported in
-next some time ago and recently made it to mainline. Linus hates when
this happen. Strictly speaking the drm folks caused this and thus would
have to fix it, too -- but there iirc was some reason why a revert was a
bad option. Hence:

could you hence do us a favor and review and mainline this rather sooner
than later? Maybe even before 7.4-rc1 to prevent more people from
running into this (three people already did afaics).

Ciao, Thorsten
> On Glymur gfx.lvl has 14 levels and the clamp holds the rail at the top
> one, 0x1d0, while the GMU's own performance table ends at level 11,
> 0x1c4.  With the GPU driver and firmware built in, the GMU boots long
> before sync_state, and its CLX DCVS calibration does not survive a gfx
> rail held that high: the firmware gives up with HFI_F2H_MSG_ERROR
> 0x007306c7 (ResMgrCalibrateDcvsLvl), the first HFI_H2F_MSG_GX_BW_PERF_VOTE
> times out and the first GPU init fails.  On the Lenovo Yoga Slim 7x
> Gen 11 this means the compositor cannot start at first login.  Pinning
> gfx at level 11 or 12 instead fails the same way, level 10 and below
> boot fine, and pinning gmxc alone has no effect.
> 
> Leave gfx and gmxc out of the clamp: they have no bootloader-configured
> consumer to protect, and the GMU votes them through its own RSC.
> 
> Fixes: 93b6c8d10fad ("drm/msm/a8xx: Enable CLX feature on Adreno X2-85")
> Link: https://lore.kernel.org/r/179248663855.32151.9955864156939592299@gmail.com
> Acked-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> Signed-off-by: Oleg Keri <okerixx@gmail.com>
> ---
>  drivers/pmdomain/qcom/rpmhpd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
> index fa8fed5bd3e5..2c9d4beeffbe 100644
> --- a/drivers/pmdomain/qcom/rpmhpd.c
> +++ b/drivers/pmdomain/qcom/rpmhpd.c
> @@ -1006,7 +1006,7 @@ static int rpmhpd_aggregate_corner(struct rpmhpd *pd, unsigned int corner)
>  	unsigned int peer_active_corner = 0, peer_sleep_corner = 0;
>  	unsigned int peer_enabled_corner;
>  
> -	if (pd->state_synced) {
> +	if (pd->state_synced || pd == &gfx || pd == &gmxc) {
>  		to_active_sleep(pd, corner, &this_active_corner, &this_sleep_corner);
>  	} else {
>  		/* Clamp to highest corner if sync_state hasn't happened */
> 
> base-commit: 2efb7a11f1aa4d2dc285fe2680cca22cb9f72f64