From: Jani Nikula <jani.nikula@linux.intel.com>
To: Vinod Govindapillai <vinod.govindapillai@intel.com>,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: vinod.govindapillai@intel.com, imre.deak@intel.com
Subject: Re: [RFC PATCH 1/5] drm/xe/pm: add xe_pm_pme_supported() helper
Date: Mon, 17 Aug 2026 13:17:19 +0300 [thread overview]
Message-ID: <97a6578c8d52c2ae8c179e8be3c1a92359f0e311@intel.com> (raw)
In-Reply-To: <20260816224005.886035-2-vinod.govindapillai@intel.com>
On Mon, 17 Aug 2026, Vinod Govindapillai <vinod.govindapillai@intel.com> wrote:
> Introduce the helper to check if the device can signal a wakeup event
> while runtime suspended. This can avoid scheduling the HPD polling.
>
> Assisted-by: GitHub_Copilot:claude-opus-5
> Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
> ---
> drivers/gpu/drm/xe/xe_pm.c | 21 +++++++++++++++++++++
> drivers/gpu/drm/xe/xe_pm.h | 1 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> index a5289a9df8d2..635bfb1c7f78 100644
> --- a/drivers/gpu/drm/xe/xe_pm.c
> +++ b/drivers/gpu/drm/xe/xe_pm.c
> @@ -937,6 +937,27 @@ bool xe_pm_runtime_resume_and_get(struct xe_device *xe)
> return pm_runtime_resume_and_get(xe->drm.dev) >= 0;
> }
>
> +/**
> + * xe_pm_pme_supported - Can the device signal PME from its suspend target state?
> + * @xe: xe device instance
> + *
> + * Determine whether the device can generate a Power Management Event while
> + * runtime suspended.
> + *
> + * Return: true if PME is supported from the target state, false otherwise.
> + */
> +bool xe_pm_pme_supported(struct xe_device *xe)
> +{
> + struct pci_dev *pdev = to_pci_dev(xe->drm.dev);
> +
> + /*
> + * pci_dev_run_wake() checks dev->pme_support, verifies
> + * pci_pme_capable() against the state pci_target_state() picks, and
> + * walks upstream to confirm the wake can actually be routed.
Is this comment helpful? pci_dev_run_wake() has a kernel-doc comment
that explains what it does?
> + */
> + return pci_dev_run_wake(pdev);
> +}
> +
> /**
> * xe_pm_assert_unbounded_bridge - Disable PM on unbounded pcie parent bridge
> * @xe: xe device instance
> diff --git a/drivers/gpu/drm/xe/xe_pm.h b/drivers/gpu/drm/xe/xe_pm.h
> index 6d5ab09cb769..16b8699e59ec 100644
> --- a/drivers/gpu/drm/xe/xe_pm.h
> +++ b/drivers/gpu/drm/xe/xe_pm.h
> @@ -30,6 +30,7 @@ bool xe_pm_runtime_get_if_active(struct xe_device *xe);
> bool xe_pm_runtime_get_if_in_use(struct xe_device *xe);
> void xe_pm_runtime_get_noresume(struct xe_device *xe);
> bool xe_pm_runtime_resume_and_get(struct xe_device *xe);
> +bool xe_pm_pme_supported(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);
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-08-17 10:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 22:39 [RFC PATCH 0/5] pm_pme support on display hotplug Vinod Govindapillai
2026-08-16 22:40 ` [RFC PATCH 1/5] drm/xe/pm: add xe_pm_pme_supported() helper Vinod Govindapillai
2026-08-17 10:17 ` Jani Nikula [this message]
2026-08-16 22:40 ` [RFC PATCH 2/5] drm/i915/display: add pme_capable() to the parent interface Vinod Govindapillai
2026-08-17 10:19 ` Jani Nikula
2026-08-18 6:54 ` Govindapillai, Vinod
2026-08-18 6:57 ` Jani Nikula
2026-08-16 22:40 ` [RFC PATCH 3/5] drm/i915/xe: plug the pme_capability query for xe Vinod Govindapillai
2026-08-16 22:40 ` [RFC PATCH 4/5] drm/i915/display: add intel_hpd_polling_enabled() Vinod Govindapillai
2026-08-16 22:40 ` [RFC PATCH 5/5] drm/i915/display: skip HPD polling if PME is supported Vinod Govindapillai
2026-08-16 22:52 ` sashiko-bot
2026-08-17 10:15 ` Jani Nikula
2026-08-16 22:48 ` ✓ CI.KUnit: success for pm_pme support on display hotplug Patchwork
2026-08-16 23:22 ` ✓ i915.CI.BAT: " Patchwork
2026-08-16 23:26 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-17 22:26 ` ✓ i915.CI.Full: success " 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=97a6578c8d52c2ae8c179e8be3c1a92359f0e311@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--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.