From: Raag Jadav <raag.jadav@intel.com>
To: Vinod Govindapillai <vinod.govindapillai@intel.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
jouni.hogander@intel.com
Subject: Re: [PATCH v7 2/7] drm/xe/pm: introduce PM PME support
Date: Tue, 15 Sep 2026 09:43:08 +0200 [thread overview]
Message-ID: <aqj3DN5CzZVOCByy@black.igk.intel.com> (raw)
In-Reply-To: <20260914204034.309566-3-vinod.govindapillai@intel.com>
On Mon, Sep 14, 2026 at 11:40:29PM +0300, Vinod Govindapillai wrote:
> Introduce PME support for PME capable devices. Whether device is
> PME capable is assessed during PCI probe routine. And the whether
> PME is enabled for a specific context is assessed during the PM
> runtime suspend call if the device is PME capable.
>
> If the PME is enabled, HPDs can generate PME which in turn call
> the runtime resume call and do the wakeup routines. Till now
> the driver was relying on HPD polling to wakeup in case of any
> HPDs. HPD polling can be avoided in platforms with PME support
> and instead rely on this PCI PME for HPD induced wakeup.
>
> v2: access functions for xe.pme.enabled status and clear the pme.
> enabled in case of error in xe_pm_runtime_suspend()
>
> v3: use the local pme_enabled flag to clear the device wakeup
> incase of error
>
> 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/xe_device_types.h | 13 ++++++++++
> drivers/gpu/drm/xe/xe_pci.c | 16 +++++++++++-
> drivers/gpu/drm/xe/xe_pm.c | 39 ++++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_pm.h | 2 ++
> 4 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index 4661bfce2f4e..bb4234f00453 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -460,6 +460,19 @@ struct xe_device {
> struct mutex lock;
> } d3cold;
>
> + /** @pme: Encapsulate pme related stuff */
> + struct {
> + /** @pme.capable: Indicates if device is PME capable */
> + bool capable;
> +
> + /** @pme.enabled:
> + *
> + * Indicates if PME is enabled - depends on user controllable
> + * sysfs interface as well
> + */
> + bool enabled;
> + } pme;
> +
> /** @pm_notifier: Our PM notifier to perform actions in response to various PM events. */
> struct notifier_block pm_notifier;
> /** @pm_block: Completion to block validating tasks on suspend / hibernate prepare */
> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 30c81042145f..3e7ee67c46f9 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -1384,8 +1384,14 @@ static int xe_pci_runtime_suspend(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> struct xe_device *xe = pdev_to_xe_device(pdev);
> + bool pme_enabled;
> int err;
>
> + pme_enabled = xe->pme.capable && !xe->d3cold.allowed &&
> + pci_enable_wake(pdev, PCI_D3hot, true) == 0;
Can't all this debt be avoided by simply letting the PCI PM take care
of it?
Raag
> + xe_pm_update_pme_enabled(xe, pme_enabled);
> +
> /*
> * We hold an additional reference to the runtime PM to keep PF in D0
> * during VFs lifetime, as our VFs do not implement the PM capability.
> @@ -1396,8 +1402,14 @@ static int xe_pci_runtime_suspend(struct device *dev)
> xe_assert(xe, !pci_num_vf(pdev));
>
> err = xe_pm_runtime_suspend(xe);
> - if (err)
> + if (err) {
> + if (pme_enabled) {
> + pci_enable_wake(pdev, PCI_D3hot, false);
> + xe_pm_update_pme_enabled(xe, false);
> + }
> +
> return err;
> + }
>
> pci_save_state(pdev);
>
> @@ -1426,6 +1438,8 @@ static int xe_pci_runtime_resume(struct device *dev)
>
> pci_restore_state(pdev);
>
> + xe_pm_update_pme_enabled(xe, false);
> +
> if (xe->d3cold.allowed) {
> err = pci_enable_device(pdev);
> if (err)
> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> index f517bf453b54..ca5665d015e9 100644
> --- a/drivers/gpu/drm/xe/xe_pm.c
> +++ b/drivers/gpu/drm/xe/xe_pm.c
> @@ -78,6 +78,8 @@
> * management (RPS).
> */
>
> +#define HAS_PM_PME_SUPPORT(xe) (GRAPHICS_VERx100(xe) >= 3500)
> +
> #ifdef CONFIG_LOCKDEP
> static struct lockdep_map xe_pm_runtime_d3cold_map = {
> .name = "xe_rpm_d3cold_map"
> @@ -384,6 +386,14 @@ int xe_pm_init_early(struct xe_device *xe)
> }
> ALLOW_ERROR_INJECTION(xe_pm_init_early, ERRNO); /* See xe_pci_probe() */
>
> +static bool xe_pm_pci_pme_capable(struct xe_device *xe)
> +{
> + struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> +
> + return HAS_PM_PME_SUPPORT(xe) ?
> + pci_pme_capable(pdev, PCI_D3hot) : false;
> +}
> +
> /**
> * xe_pm_probe() - Initialize Xe Power Management
> * @xe: the &xe_device instance
> @@ -397,6 +407,9 @@ int xe_pm_probe(struct xe_device *xe)
> xe->d3cold.capable = xe_pm_pci_d3cold_capable(xe);
> xe_dbg(xe, "d3cold: capable=%s\n", str_yes_no(xe->d3cold.capable));
>
> + xe->pme.capable = xe_pm_pci_pme_capable(xe);
> + xe_dbg(xe, "pme: capable=%s\n", str_yes_no(xe->pme.capable));
> +
> return 0;
> }
>
> @@ -650,6 +663,7 @@ int xe_pm_runtime_suspend(struct xe_device *xe)
> return 0;
>
> out_resume:
> + xe_pm_update_pme_enabled(xe, false);
> xe_display_pm_runtime_resume(xe);
> xe_pxp_pm_resume(xe->pxp);
> out:
> @@ -993,6 +1007,31 @@ int xe_pm_set_vram_threshold(struct xe_device *xe, u32 threshold)
> return 0;
> }
>
> +/**
> + * xe_pm_pme_enabled - get the current state of PME enabled status
> + * @xe: xe device instance
> + *
> + * Return:
> + * * True if PME is enabled, false otherwise.
> + */
> +bool xe_pm_pme_enabled(struct xe_device *xe)
> +{
> + return xe->pme.enabled;
> +}
> +
> +/**
> + * xe_pm_update_pme_enabled - Update the PME enabled state
> + * @xe: xe device instance
> + * @status: New PME enabled status
> + *
> + * Called during runtime suspend / resume with status set to True if PME is
> + * enabled during runtime_suspend. Cleared on runtime_resume.
> + */
> +void xe_pm_update_pme_enabled(struct xe_device *xe, bool status)
> +{
> + xe->pme.enabled = status;
> +}
> +
> /**
> * xe_pm_d3cold_allowed_toggle - Check conditions to toggle d3cold.allowed
> * @xe: xe device instance
> diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h
> index 6d5ab09cb769..037c73ea4342 100644
> --- a/drivers/gpu/drm/xe/xe_pm.h
> +++ b/drivers/gpu/drm/xe/xe_pm.h
> @@ -33,6 +33,8 @@ bool xe_pm_runtime_resume_and_get(struct xe_device *xe);
> void xe_pm_assert_unbounded_bridge(struct xe_device *xe);
> int xe_pm_set_vram_threshold(struct xe_device *xe, u32 threshold);
> void xe_pm_d3cold_allowed_toggle(struct xe_device *xe);
> +bool xe_pm_pme_enabled(struct xe_device *xe);
> +void xe_pm_update_pme_enabled(struct xe_device *xe, bool status);
> bool xe_rpm_reclaim_safe(const struct xe_device *xe);
> struct task_struct *xe_pm_read_callback_task(struct xe_device *xe);
> int xe_pm_block_on_suspend(struct xe_device *xe);
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-09-15 7:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 20:40 [PATCH v7 0/7] pm_pme support on display hotplug Vinod Govindapillai
2026-09-14 20:40 ` [PATCH v7 1/7] drm/xe/pm: initialize the device's system wakeup capabilities Vinod Govindapillai
2026-09-14 20:40 ` [PATCH v7 2/7] drm/xe/pm: introduce PM PME support Vinod Govindapillai
2026-09-14 20:53 ` sashiko-bot
2026-09-15 7:43 ` Raag Jadav [this message]
2026-09-14 20:40 ` [PATCH v7 3/7] drm/xe/pm: avoid reclaim when arming PME wakeup Vinod Govindapillai
2026-09-14 20:40 ` [PATCH v7 4/7] drm/i915: add pme_enabled() to the parent interface Vinod Govindapillai
2026-09-14 20:40 ` [PATCH v7 5/7] drm/i915/xe: plug the pme_enabed implementation for xe Vinod Govindapillai
2026-09-14 20:40 ` [PATCH v7 6/7] drm/i915/irq: conditional HPD IRQ resets based on PME capability Vinod Govindapillai
2026-09-14 21:07 ` sashiko-bot
2026-09-14 20:40 ` [PATCH v7 7/7] drm/i915/hotplug: avoid HPD polling if the device is PME capable Vinod Govindapillai
2026-09-14 20:49 ` ✓ CI.KUnit: success for pm_pme support on display hotplug (rev7) Patchwork
2026-09-14 21:27 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-15 2:43 ` ✓ Xe.CI.FULL: " 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=aqj3DN5CzZVOCByy@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jouni.hogander@intel.com \
--cc=vinod.govindapillai@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