Re: [PATCH 6/6] drm/msm/a6xx: Limit GXPD votes to recovery in A8x
From: Akhil P Oommen
Date: Wed Apr 15 2026 - 16:53:31 EST
On 4/14/2026 7:58 PM, Konrad Dybcio wrote:
> On 4/7/26 9:16 PM, Akhil P Oommen wrote:
>> On 4/7/2026 4:31 PM, Konrad Dybcio wrote:
>>> On 4/7/26 11:30 AM, Taniya Das wrote:
>>>> From: Akhil P Oommen <akhilpo@xxxxxxxxxxxxxxxx>
>>>>
>>>> In A8x GPUs, the GX GDSC is moved to a separate block called GXCLKCTL
>>>> which is under the GX power domain. Due to the way the support for this
>>>> block is implemented in its driver, pm_runtime votes result in a vote on
>>>> GX/GMxC/MxC rails from the APPS RSC. This is against the Adreno
>>>> architecture which require GMU to be the sole voter of these collapsible
>>>> rails on behalf of GPU, except during the GPU/GMU recovery.
>>>>
>>>> To align with this architectural requirement and to realize the power
>>>> benefits of the IFPC feature, remove the GXPD votes during gmu resume
>>>> and suspend. And during the recovery sequence, enable/disable the GXPD
>>>> along with the 'synced_poweroff' genpd hint to force collapse this GDSC.
>>>>
>>>> Signed-off-by: Akhil P Oommen <akhilpo@xxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Taniya Das <taniya.das@xxxxxxxxxxxxxxxx>
>>>> ---
>>>
>>> Can we simply make this change unconditional on the gen, so as not to
>>> maintain 2 separate code paths that try to achieve mostly the same thing?
>>
>> We can skip the gdsc vote on A8x because the 'gdsc disable' callback is
>> dummy when the synced_poweroff hint is not set. Otherwise, gdsc may get
>> disabled during system resume while GMU assumes the ownership. Taniya
>> touched upon this point in the cover letter:
>>
>> """
>> when GX GDSC is managed through the generic GenPD runtime PM
>> framework, it can be unintentionally disabled by the OS during system
>> resume (resume_noirq/complete phases) or runtime PM suspend paths.
>> """
>
> Right, but if we made the GDSC.disable() a dummy on all platforms this
> could be done.
>
> On a second thought though, this won't work for gmu_wrapper, so we'd
> need two paths either way.
gmu_wrapper uses a different code path for pm_resume/suspend anyway. So,
that is not a problem.
Perhaps, we can explore this separately as it would impact a lot of
chipsets. I would like the get this series merged ASAP to unblock A8x
support.
-Akhil.
>
> Konrad