[PATCH 01/10] drm/amd/display: temp w/a for dGPU to enter idle optimizations

[Pillai, Aurabindo]

[Public]


Hi Mario,

Hamza is working on the reported issue and appears to be due to a different root cause. Hence, we're expecting that the fix for that issue is likely going to be different, with what we know so far. While that issue is being debugged, this patch will allow us to have better idle power consumption on dGPUs


--

Regards,
Jay
________________________________
From: Limonciello, Mario <Mario.Limonciello at amd.com>
Sent: Tuesday, October 15, 2024 9:14 AM
To: Lin, Wayne <Wayne.Lin at amd.com>; amd-gfx at lists.freedesktop.org <amd-gfx at lists.freedesktop.org>
Cc: Wentland, Harry <Harry.Wentland at amd.com>; Li, Sun peng (Leo) <Sunpeng.Li at amd.com>; Siqueira, Rodrigo <Rodrigo.Siqueira at amd.com>; Mahfooz, Hamza <Hamza.Mahfooz at amd.com>; Pillai, Aurabindo <Aurabindo.Pillai at amd.com>; Li, Roman <Roman.Li at amd.com>; Chung, ChiaHsuan (Tom) <ChiaHsuan.Chung at amd.com>; Zuo, Jerry <Jerry.Zuo at amd.com>; Mohamed, Zaeem <Zaeem.Mohamed at amd.com>; Chiu, Solomon <Solomon.Chiu at amd.com>; Wheeler, Daniel <Daniel.Wheeler at amd.com>; Deucher, Alexander <Alexander.Deucher at amd.com>; stable at vger.kernel.org <stable at vger.kernel.org>
Subject: Re: [PATCH 01/10] drm/amd/display: temp w/a for dGPU to enter idle optimizations

On 10/15/2024 03:17, Wayne Lin wrote:
> From: Aurabindo Pillai <aurabindo.pillai at amd.com>
>
> [Why&How]
> vblank immediate disable currently does not work for all asics. On
> DCN401, the vblank interrupts never stop coming, and hence we never
> get a chance to trigger idle optimizations.
>
> Add a workaround to enable immediate disable only on APUs for now. This
> adds a 2-frame delay for triggering idle optimization, which is a
> negligible overhead.
>
> Fixes: db11e20a1144 ("drm/amd/display: use a more lax vblank enable policy for older ASICs")
> Fixes: 6dfb3a42a914 ("drm/amd/display: use a more lax vblank enable policy for DCN35+")
>
> Cc: Mario Limonciello <mario.limonciello at amd.com>
> Cc: Alex Deucher <alexander.deucher at amd.com>
> Cc: stable at vger.kernel.org
> Reviewed-by: Harry Wentland <harry.wentland at amd.com>
> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira at amd.com>
> Signed-off-by: Aurabindo Pillai <aurabindo.pillai at amd.com>
> Signed-off-by: Wayne Lin <wayne.lin at amd.com>
> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a4882b16ace2..6ea54eb5d68d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8379,7 +8379,8 @@ static void manage_dm_interrupts(struct amdgpu_device *adev,
>                if (amdgpu_ip_version(adev, DCE_HWIP, 0) <
>                    IP_VERSION(3, 5, 0) ||
>                    acrtc_state->stream->link->psr_settings.psr_version <
> -                 DC_PSR_VERSION_UNSUPPORTED) {
> +                 DC_PSR_VERSION_UNSUPPORTED ||
> +                 !(adev->flags & AMD_IS_APU)) {
>                        timing = &acrtc_state->stream->timing;
>
>                        /* at least 2 frames */

Considering the regression raised [1] is on an APU too I wonder if this
is really the best workaround to approach to this issue.

https://lore.kernel.org/amd-gfx/9b80e957-f20a-4bd7-a40b-2b5f1decf5a4@johnrowley.me/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20241016/aff42d02/attachment.htm>