From: Jani Nikula <jani.nikula@intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
ville.syrjala@linux.intel.com
Subject: Re: [PATCH 3/4] drm/xe/display: separate d3cold handling from xe_display_pm_runtime_suspend_late()
Date: Mon, 15 Jun 2026 23:34:34 +0300 [thread overview]
Message-ID: <9845ff6706dd137390b5474af1358dfc6bbed501@intel.com> (raw)
In-Reply-To: <ajBb9sgCnlh22eY_@intel.com>
On Mon, 15 Jun 2026, Rodrigo Vivi <rodrigo.vivi@intel.com> 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 <rodrigo.vivi@intel.com>
>> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> ---
>> 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 <rodrigo.vivi@intel.com>
Thanks!
BR,
Jani.
>
>> }
>>
>> --
>> 2.47.3
>>
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-06-15 20:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 12:40 [PATCH 0/4] drm/{i915,xe}: unify runtime pm calls Jani Nikula
2026-06-15 12:40 ` [PATCH 1/4] drm/i915: add intel_display_driver_pm_runtime*() functions Jani Nikula
2026-06-15 12:40 ` [PATCH 2/4] drm/{i915, xe}: add new intel_display_driver_runtime_pm_{enable, disable}() Jani Nikula
2026-06-15 20:01 ` [PATCH 2/4] drm/{i915,xe}: add new intel_display_driver_runtime_pm_{enable,disable}() Rodrigo Vivi
2026-06-15 12:40 ` [PATCH 3/4] drm/xe/display: separate d3cold handling from xe_display_pm_runtime_suspend_late() Jani Nikula
2026-06-15 20:09 ` Rodrigo Vivi
2026-06-15 20:34 ` Jani Nikula [this message]
2026-06-15 12:40 ` [PATCH 4/4] drm/xe/display: unify runtime suspend/resume with i915 for non-d3cold Jani Nikula
2026-06-15 12:48 ` ✓ CI.KUnit: success for drm/{i915,xe}: unify runtime pm calls Patchwork
2026-06-15 13:46 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-06-15 14:41 ` ✗ Xe.CI.FULL: " Patchwork
2026-06-15 15:10 ` ✓ i915.CI.BAT: success " Patchwork
2026-06-15 19:52 ` ✗ i915.CI.Full: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9845ff6706dd137390b5474af1358dfc6bbed501@intel.com \
--to=jani.nikula@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.