From: sashiko-bot@kernel.org
To: "Vinod Govindapillai" <vinod.govindapillai@intel.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Subject: Re: [RFC PATCH 5/5] drm/i915/display: skip HPD polling if PME is supported
Date: Sun, 16 Aug 2026 22:52:05 +0000 [thread overview]
Message-ID: <20260816225205.8B47B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260816224005.886035-6-vinod.govindapillai@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Skipping `intel_hpd_init()` on runtime resume for PME-capable devices leaves hardware HPD interrupts permanently disabled, breaking hotplug detection while the device is awake.
--
--- Patch [5]: [RFC PATCH 5/5] drm/i915/display: skip HPD polling if PME is supported ---
commit f6a80f590c41d181052f2d40a190e9c030e50eb2
Author: Vinod Govindapillai <vinod.govindapillai@intel.com>
drm/i915/display: skip HPD polling if PME is supported
This commit prevents the display driver from enabling HPD polling during
runtime suspend if the device supports PM_PME. It also updates the resume
path to selectively initialize HPD only if polling was actually enabled.
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 70d112fd4287a..b7e25b7ea32ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
[ ... ]
> @@ -951,10 +956,20 @@ void intel_display_driver_pm_runtime_resume(struct intel_display *display)
> * power well, so hpd is reinitialized from there. For
> * everyone else do it here.
> */
> - if (!display->platform.valleyview && !display->platform.cherryview) {
> + if (display->platform.valleyview || display->platform.cherryview)
> + goto out;
> +
> + /* For PME capable devices we would not have resorted into HPD polling */
> + if (intel_hpd_polling_enabled(display))
> intel_hpd_init(display);
[Severity: High]
Does skipping intel_hpd_init() here permanently break hardware hotplug
detection for PME-capable devices?
When a PME-capable device enters runtime suspend, it skips
intel_hpd_poll_enable(), so intel_hpd_polling_enabled() will return false.
On resume, this condition causes intel_hpd_init() to be skipped.
However, looking at intel_hpd_init() in intel_hotplug.c, it does more than
just polling setup. It also programs the hardware registers to re-enable
hardware interrupts:
void intel_hpd_init(struct intel_display *display)
{
...
spin_lock_irq(&display->irq.lock);
intel_hpd_irq_setup(display);
spin_unlock_irq(&display->irq.lock);
}
Without calling intel_hpd_irq_setup(), the hardware HPD interrupts will
remain masked. Will any subsequent monitor hotplugs or unplugs that happen
while the device is awake be silently ignored?
> - intel_hpd_poll_disable(display);
> - }
>
> + /*
> + * Regardless of PME capable path, call the HPD polling disable, the
> + * poll_init_work, i915_hpd_poll_detect_connectors reprobe catches the
> + * hotplug that occurred while suspended
> + */
> + intel_hpd_poll_disable(display);
> +
> +out:
> skl_watermark_ipc_update(display);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260816224005.886035-1-vinod.govindapillai@intel.com?part=5
next prev parent reply other threads:[~2026-08-16 22:52 UTC|newest]
Thread overview: 14+ 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
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-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 [this message]
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=20260816225205.8B47B1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--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.