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

From: Denis Zornada

Date: Wed Oct 21 2026 - 06:07:24 EST


(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@xxxxxxxxxxx> # Zenbook A16