All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  parent reply	other threads:[~2026-09-15  7:43 UTC|newest]

Thread overview: 16+ 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-14 21:49 ` ✓ i915.CI.BAT: " Patchwork
2026-09-15  2:43 ` ✓ Xe.CI.FULL: " Patchwork
2026-09-15  3:16 ` ✓ i915.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 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.