From: Imre Deak <imre.deak@intel.com>
To: "Cavitt, Jonathan" <jonathan.cavitt@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 1/2] drm/xe: Separate the d3cold and non-d3cold runtime PM handling
Date: Mon, 7 Oct 2024 21:45:08 +0300 [thread overview]
Message-ID: <ZwQsNDhqq6mGkOPS@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <BL1PR11MB54456F054673E415F0A65698E57D2@BL1PR11MB5445.namprd11.prod.outlook.com>
On Mon, Oct 07, 2024 at 09:28:52PM +0300, Cavitt, Jonathan wrote:
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Imre Deak
> Sent: Monday, October 7, 2024 7:06 AM
> To: intel-xe@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Vivi, Rodrigo <rodrigo.vivi@intel.com>
> Subject: [PATCH 1/2] drm/xe: Separate the d3cold and non-d3cold runtime PM handling
> >
> > For clarity separate the d3cold and non-d3cold runtime PM handling. The
> > only change in behavior is disabling polling later during runtime
> > resume. This shouldn't make a difference, since the poll disabling is
> > handled from a work, which could run at any point wrt. the runtime
> > resume handler. The work will also require a runtime PM reference,
> > syncing it with the resume handler.
> >
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
>
> It seems a bit weird to me that we're enabling hpd polling during the suspend
> path and disabling it during the resume path, especially given the second patch's
> commit message mentioning that HPD interrupts are getting disabled in the
> suspend path.
Yes, the above summary is correct: interrupts must be disabled while the
device is runtime suspended, so polling should be used instead to detect
display hotplug events. Accordingly runtime resume reverses this,
disabling polling and enabling interrupts.
> However, I just looked, and it seems like this is the way it has been
> since the beginning, so I'm going to trust that it's supposed to be this way.
>
> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Thanks.
> -Jonathan Cavitt
>
> > ---
> > drivers/gpu/drm/xe/display/xe_display.c | 19 ++++++++++++++-----
> > 1 file changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/display/xe_display.c b/drivers/gpu/drm/xe/display/xe_display.c
> > index ca00a365080fb..cb2449b7921ac 100644
> > --- a/drivers/gpu/drm/xe/display/xe_display.c
> > +++ b/drivers/gpu/drm/xe/display/xe_display.c
> > @@ -345,6 +345,9 @@ static void __xe_display_pm_suspend(struct xe_device *xe, bool runtime)
> > intel_opregion_suspend(display, s2idle ? PCI_D1 : PCI_D3cold);
> >
> > intel_dmc_suspend(display);
> > +
> > + if (runtime && has_display(xe))
> > + intel_hpd_poll_enable(xe);
> > }
> >
> > void xe_display_pm_suspend(struct xe_device *xe)
> > @@ -387,8 +390,10 @@ void xe_display_pm_runtime_suspend(struct xe_device *xe)
> > if (!xe->info.probe_display)
> > return;
> >
> > - if (xe->d3cold.allowed)
> > + if (xe->d3cold.allowed) {
> > __xe_display_pm_suspend(xe, true);
> > + return;
> > + }
> >
> > intel_hpd_poll_enable(xe);
> > }
> > @@ -453,9 +458,11 @@ static void __xe_display_pm_resume(struct xe_device *xe, bool runtime)
> > intel_display_driver_resume(xe);
> > drm_kms_helper_poll_enable(&xe->drm);
> > intel_display_driver_enable_user_access(xe);
> > - intel_hpd_poll_disable(xe);
> > }
> >
> > + if (has_display(xe))
> > + intel_hpd_poll_disable(xe);
> > +
> > intel_opregion_resume(display);
> >
> > if (!runtime)
> > @@ -474,10 +481,12 @@ void xe_display_pm_runtime_resume(struct xe_device *xe)
> > if (!xe->info.probe_display)
> > return;
> >
> > - intel_hpd_poll_disable(xe);
> > -
> > - if (xe->d3cold.allowed)
> > + if (xe->d3cold.allowed) {
> > __xe_display_pm_resume(xe, true);
> > + return;
> > + }
> > +
> > + intel_hpd_poll_disable(xe);
> > }
> >
> >
> > --
> > 2.44.2
> >
> >
next prev parent reply other threads:[~2024-10-07 18:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-07 14:05 [PATCH 1/2] drm/xe: Separate the d3cold and non-d3cold runtime PM handling Imre Deak
2024-10-07 14:05 ` [PATCH 2/2] drm/xe: Add missing HPD interrupt enabling during non-d3cold RPM resume Imre Deak
2024-10-07 18:29 ` Cavitt, Jonathan
2024-10-07 18:46 ` Imre Deak
2024-10-07 18:52 ` Rodrigo Vivi
2024-10-08 15:33 ` Imre Deak
2024-10-08 20:21 ` Rodrigo Vivi
2024-10-07 18:28 ` [PATCH 1/2] drm/xe: Separate the d3cold and non-d3cold runtime PM handling Cavitt, Jonathan
2024-10-07 18:45 ` Imre Deak [this message]
2024-10-08 4:18 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
2024-10-09 5:29 ` ✗ Fi.CI.IGT: 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=ZwQsNDhqq6mGkOPS@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=rodrigo.vivi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox