On Mon, 15 Jun 2026, Rodrigo Vivi <[email protected]> wrote: > On Mon, Jun 15, 2026 at 03:40:47PM +0300, Jani Nikula wrote: >> Make the special d3cold paths completely separate from the rest of the >> runtime pm calls. >> >> The intel_dmc_wl_flush_release_work() call right after >> xe_display_pm_suspend_late() might be completely redundant, but this >> avoids any functional changes. >> >> Wiggle the comment while at it. It gets duplicated for now, but this >> will be addressed in the follow-up. >> >> v2: Update comments >> >> Cc: Rodrigo Vivi <[email protected]> >> Acked-by: Ville Syrjälä <[email protected]> >> Signed-off-by: Jani Nikula <[email protected]> >> --- >> drivers/gpu/drm/xe/display/xe_display.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/xe/display/xe_display.c >> b/drivers/gpu/drm/xe/display/xe_display.c >> index 493e9e09b6c9..bdafc010fae1 100644 >> --- a/drivers/gpu/drm/xe/display/xe_display.c >> +++ b/drivers/gpu/drm/xe/display/xe_display.c >> @@ -389,14 +389,14 @@ void xe_display_pm_runtime_suspend_late(struct >> xe_device *xe) >> if (!xe->info.probe_display) >> return; >> >> - if (xe->d3cold.allowed) >> + if (xe->d3cold.allowed) { >> xe_display_pm_suspend_late(xe); >> + /* Ensure the wakelock release work gets flushed */ >> + intel_dmc_wl_flush_release_work(display); >> + return; >> + } >> >> - /* >> - * If xe_display_pm_suspend_late() is not called, it is likely >> - * that we will be on dynamic DC states with DMC wakelock enabled. We >> - * need to flush the release work in that case. >> - */ >> + /* Ensure the wakelock release work gets flushed */ >> intel_dmc_wl_flush_release_work(display); > > In the next patch you end up removing this entirely, so I'm wondering > why this patch simply doesn't remove this and move it to the d3cold only?! > > I mean, I saw you replace that by the new runtime_ calls that does the > power_disable, but I don't see that calling the flush, so why simply not > remove now on this patch and make that next one only adding that runtime call > here?
I believe the flush is *deep* down the call path there. > > But well, this patch itself is not wrong and it does what it tells and > you are transparently telling this is for ne follow up work. So, > > Reviewed-by: Rodrigo Vivi <[email protected]> Thanks! BR, Jani. > >> } >> >> -- >> 2.47.3 >> -- Jani Nikula, Intel
