[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 <[email protected]> Sent: Tuesday, October 15, 2024 9:14 AM To: Lin, Wayne <[email protected]>; [email protected] <[email protected]> Cc: Wentland, Harry <[email protected]>; Li, Sun peng (Leo) <[email protected]>; Siqueira, Rodrigo <[email protected]>; Mahfooz, Hamza <[email protected]>; Pillai, Aurabindo <[email protected]>; Li, Roman <[email protected]>; Chung, ChiaHsuan (Tom) <[email protected]>; Zuo, Jerry <[email protected]>; Mohamed, Zaeem <[email protected]>; Chiu, Solomon <[email protected]>; Wheeler, Daniel <[email protected]>; Deucher, Alexander <[email protected]>; [email protected] <[email protected]> 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 <[email protected]> > > [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 <[email protected]> > Cc: Alex Deucher <[email protected]> > Cc: [email protected] > Reviewed-by: Harry Wentland <[email protected]> > Reviewed-by: Rodrigo Siqueira <[email protected]> > Signed-off-by: Aurabindo Pillai <[email protected]> > Signed-off-by: Wayne Lin <[email protected]> > --- > 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/[email protected]/
