Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Hogander, Jouni" <jouni.hogander@intel.com>,
	"jani.nikula@linux.intel.com" <jani.nikula@linux.intel.com>
Cc: "Deak, Imre" <imre.deak@intel.com>
Subject: Re: [PATCH v2 5/5] drm/xe/pm: handle the PME capability and runtime pm routines
Date: Tue, 8 Sep 2026 07:41:20 +0000	[thread overview]
Message-ID: <72062813fd0dd71f67e0d201e628091bb8cd7d5f.camel@intel.com> (raw)
In-Reply-To: <83e32e6c3fafdc6a5da34593718a8a403ccd3695.camel@intel.com>

On Tue, 2026-09-08 at 06:19 +0000, Hogander, Jouni wrote:
> On Fri, 2026-09-04 at 13:03 +0300, Jani Nikula wrote:
> > On Thu, 03 Sep 2026, Vinod Govindapillai
> > <vinod.govindapillai@intel.com> wrote:
> > > During the runtime suspend, check if device is capable of wakeup
> > > from PME. If yes update the helper so that IRQ reset and HPD
> > > polling can be handled accordingly. For PME capable devices,
> > > HPD related IRQs are not reset during runtime suspend and
> > > do not start polling for HPDs every 10s. Instead PME can be
> > > generated from HPDs and corresponding runtime resume calls
> > > can be invoked by PME.
> > > 
> > > Bspec: 52979, 52980, 68857, 68867, 68970
> > > Assisted-by: GitHub_Copilot:claude-opus-5
> > > Signed-off-by: Vinod Govindapillai
> > > <vinod.govindapillai@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/display/xe_display.c | 10 ++++++++++
> > >  drivers/gpu/drm/xe/display/xe_display.h |  4 ++++
> > >  drivers/gpu/drm/xe/xe_pci.c             | 16 +++++++++++++++-
> > >  3 files changed, 29 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/display/xe_display.c
> > > b/drivers/gpu/drm/xe/display/xe_display.c
> > > index 7b25c0814674..ff4a74c5c763 100644
> > > --- a/drivers/gpu/drm/xe/display/xe_display.c
> > > +++ b/drivers/gpu/drm/xe/display/xe_display.c
> > > @@ -236,6 +236,16 @@ void xe_display_irq_postinstall(struct
> > > xe_device *xe)
> > >  	intel_display_irq_postinstall(display);
> > >  }
> > >  
> > > +void xe_display_set_pme_capable(struct xe_device *xe, bool
> > > pme_from_hpd)
> > > +{
> > > +	struct intel_display *display = xe->display;
> > > +
> > > +	if (!xe->info.probe_display)
> > > +		return;
> > > +
> > > +	intel_hpd_set_pme_capable(display, pme_from_hpd);
> > 
> > The downside with this is that I've been trying hard to *reduce*
> > the
> > number of direct low-level calls from i915 and xe core to display.
> > 
> > There are 100+ calls already. IMO we need to drop them to the
> > ballpark
> > of less than half.
> > 
> > This would go directly to a TODO list of things to refactor and
> > clean
> > up.
> > 
> > Feels like it would be more clean with a parent interface for the
> > display to ask if pme is available, when needed, even though the
> > parent
> > interface is also too big...
> 
> Would it be ok to solve this by doing all this in display runtime
> callbacks?
> 
> Possible d3cold entry could be found out by using pci_target_state.
> 
> Is it ok to acces pci device (pci_enable_wake and pci_target_state)
> in
> display pm runtime callbacks.
> 
> BR,
> Jouni Högander
> 
> > 
> > BR,
> > Jani.
> > 
> > 
> > 

> > 
Btw, there is an updated version of this patch.. the diff is 

+#define HAS_PM_PME_SUPPORT(xe) (GRAPHICS_VERx100(xe) >= 3500)
+bool xe_pm_pme_supported(struct xe_device *xe)
+{
+	struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
+
+	if (!HAS_PM_PME_SUPPORT(xe))
+		return false;
+
+	if (!device_may_wakeup(&pdev->dev))
+		return false;
+
+	return pci_dev_run_wake(pdev);
+}

Because I noticed that we need to call "pci_dev_run_wake" to see the hw
policy also supports PME. device_may_wakeup() check the any user
controlled changes to the wakeup policy through debugfs.
HAS_PM_PME_SUPPORT() for the bspec.. which is not really needed I think
- pci_dev_run_wake() should handle that. But anyway this gives a
clarity when this feature was introduced and if any other code
variations are required in future.

Also note, pci_target_state() is a static function. But anyway
pci_dev_run_wake() use that internally to see return if PME if
supported.

Trying to solve two things here..

1. if PME is supported we need to avoid HPD IRQ resets during xe IRQ
resets which is part of the suspend routine.

2. Avoid HPD polling

Well.. I wasn't super happy about this intel_hpd_set_pme_capable()
interface. The alternative is "keep_Hpd" plumbed in to the IRQ reset
calls in the previous iteration, to avoid resetting HPD IRQs for PME.

So far intel_hpd_init, intel_hpd_poll_enable/disable are being called
from xedisplay and have common implementation for xe and i915. Thats
the reason I didnt move this to the intel_parent interface.

Also I wanted to keep a single point check for the pme_capablity in
xe_pci_runtime_suspend() so that the source of the logic for avoiding
HPD IRQ resets and avoiding HPD polling from a single call to check pme
capability - as /sys/bus/pci/devices/0000:00:02.0/power/wakeup could
affect the wakeup policy.

BR
Vinod 

  reply	other threads:[~2026-09-08  7:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03  8:04 [PATCH v2 0/5] PM_PME support on display hotplug Vinod Govindapillai
2026-09-03  8:04 ` [PATCH v2 1/5] drm/xe/pm: initialize the device's system wakeup capabilities Vinod Govindapillai
2026-09-03  8:15   ` sashiko-bot
2026-09-03  8:04 ` [PATCH v2 2/5] drm/i915/hotplug: add helpers to track HPDs can generate PME Vinod Govindapillai
2026-09-03  8:04 ` [PATCH v2 3/5] drm/i915/irq: conditional HPD IRQ resets based on PME capability Vinod Govindapillai
2026-09-03  8:32   ` sashiko-bot
2026-09-04  9:56   ` Jani Nikula
2026-09-04 12:12     ` Govindapillai, Vinod
2026-09-03  8:04 ` [PATCH v2 4/5] drm/i915/hotplug: avoid HPD polling if the device is PME capable Vinod Govindapillai
2026-09-03  8:04 ` [PATCH v2 5/5] drm/xe/pm: handle the PME capability and runtime pm routines Vinod Govindapillai
2026-09-03 12:36   ` [PATCH v3 " Vinod Govindapillai
2026-09-04 10:03   ` [PATCH v2 " Jani Nikula
2026-09-08  6:19     ` Hogander, Jouni
2026-09-08  7:41       ` Govindapillai, Vinod [this message]
2026-09-11  8:10         ` Govindapillai, Vinod
2026-09-03 10:26 ` ✓ i915.CI.BAT: success for pm_pme support on display hotplug (rev3) Patchwork
2026-09-03 14:15 ` ✗ i915.CI.BAT: failure for pm_pme support on display hotplug (rev4) 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=72062813fd0dd71f67e0d201e628091bb8cd7d5f.camel@intel.com \
    --to=vinod.govindapillai@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jouni.hogander@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