Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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: [PATCH 2/4] drm/xe/pm: plumb PME capability to runtime suspend handler
Date: Wed, 26 Aug 2026 23:04:01 +0000	[thread overview]
Message-ID: <20260826230401.9415A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260826225338.804902-3-vinod.govindapillai@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing rollback of GT suspend operations on error paths in PM suspend callbacks leaves previously suspended GTs in a powered-down state.
--

commit beb79b15731f1c3df49e1a0d1e8cf997804da5af
Author: Vinod Govindapillai <vinod.govindapillai@intel.com>
Subject: drm/xe/pm: plumb PME capability to runtime suspend handler

If the device is PME capable, we don't need to start the HPD polling
during the runtime suspend. This patch plumbs the pme_capable flag
through the runtime suspend stack.

> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> index 1488c4dfcc055..c3a53c5f8b330 100644
> --- a/drivers/gpu/drm/xe/xe_pm.c
> +++ b/drivers/gpu/drm/xe/xe_pm.c
[ ... ]
> @@ -639,9 +640,9 @@ int xe_pm_runtime_suspend(struct xe_device *xe)
>  			goto out_resume;
                        ^^^^^^^^^^^^^^^

[Severity: High]
This isn't a bug introduced by this patch, but modifying this function
highlights incomplete error handling on this path.

If suspending a GT fails (e.g., due to a forcewake timeout), the out_resume
error path skips resuming the GTs that successfully suspended prior to the
failure:

out_resume:
	xe_display_pm_runtime_resume(xe);
	xe_pxp_pm_resume(xe->pxp);
out:
	xe_rpm_lockmap_release(xe);
	xe_pm_write_callback_task(xe, NULL);
	return err;

Since the PM core considers the device to be active when the suspend callback
returns an error, won't subsequent accesses to the successfully suspended GTs
cause hardware hangs or kernel oops?

Also, a similar issue appears in the system suspend path in xe_pm_suspend():

	for_each_gt(gt, xe, id) {
		err = xe_gt_suspend(gt);
		if (err)
			goto err_display;
	}

Could we ensure previously suspended GTs are properly resumed in these error
paths?

>  	}
>  
> -	xe_irq_suspend(xe, false);
> +	xe_irq_suspend(xe, pme_capable);
>  
> -	xe_display_pm_runtime_suspend_late(xe);
> +	xe_display_pm_runtime_suspend_late(xe, pme_capable);
>  
>  	xe_i2c_pm_suspend(xe);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826225338.804902-1-vinod.govindapillai@intel.com?part=2

  reply	other threads:[~2026-08-26 23:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26 22:53 [PATCH 0/4] PM_PME support on display hotplug Vinod Govindapillai
2026-08-26 22:53 ` [PATCH 1/4] drm/i915/hpd: plumb keep_hpd through irq reset Vinod Govindapillai
2026-08-26 23:08   ` sashiko-bot
2026-08-26 22:53 ` [PATCH 2/4] drm/xe/pm: plumb PME capability to runtime suspend handler Vinod Govindapillai
2026-08-26 23:04   ` sashiko-bot [this message]
2026-08-26 22:53 ` [PATCH 3/4] drm/xe/pm: allow the device to signal PME from D3hot Vinod Govindapillai
2026-08-26 23:01   ` sashiko-bot
2026-08-26 22:53 ` [PATCH 4/4] drm/i915/display: Avoid HPD polling if the device is PME capable Vinod Govindapillai
2026-08-26 23:02 ` ✓ CI.KUnit: success for pm_pme support on display hotplug (rev2) Patchwork
2026-08-26 23:38 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-27  2:02 ` ✓ 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=20260826230401.9415A1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox