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

[johannes.goede@oss.qualcomm.com]

Hi Ulf,

On 13-Nov-26 18:48, Ulf Hansson wrote:
> On Wed, Oct 21, 2026 at 10:05 AM Oleg Keri <okerixx@gmail.com> 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.
>>
>> 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>
> 
> Applied for fixes and by adding a stable tag, thanks!

Nice, thank you.

Talking about regression fixes, any chance you can take a look at
this MMC fix, which as the cover letter explains also is sorta
a regression fix (the root cause is not a regression but other
7.4 changes make it easier to trigger):

https://lore.kernel.org/linux-mmc/20261112124430.110629-1-johannes.goede@oss.qualcomm.com/

and if your happy with the fix can you queue this up for
7/4-rc# merging?

Regards,

Hans