Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Vinay Belgaumkar" <vinay.belgaumkar@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/xe: Inspect all forcewake bits for runtime idleness
Date: Thu, 10 Sep 2026 22:14:49 +0000	[thread overview]
Message-ID: <20260910221449.E9E191F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260910215756.2393137-1-vinay.belgaumkar@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The GT idleness check is bypassed when the autosuspend timer expires, causing the device to incorrectly suspend while GT force wake bits are set.
--

commit 67a69146e56125d81bcb8e5c162581fbabbf0d56
Author: Vinay Belgaumkar <vinay.belgaumkar@intel.com>

    drm/xe: Inspect all forcewake bits for runtime idleness

    Inspect all GT force wake bits in the idle check for runtime suspend.
    This includes the ones not typically used by Xe KMD as well. Skip suspend
    when any of these bits are set, since it could mean someone is trying to
    keep the GT awake.
    
    Also add a call to pm_runtime_autosuspend() inside the idle check. This
    ensures a PM subsystem retry at a later time.

> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 1e04e8ef2611f..278cfd390364c 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c
> @@ -1437,10 +1437,14 @@ static int xe_pci_runtime_idle(struct device *dev)
>  {
>  	struct pci_dev *pdev = to_pci_dev(dev);
>  	struct xe_device *xe = pdev_to_xe_device(pdev);
> +	int ret;
>  
>  	xe_pm_d3cold_allowed_toggle(xe);
>  
> -	return 0;
> +	ret = xe_pm_check_runtime_idle(xe);
> +	pm_runtime_autosuspend(dev);
> +
> +	return ret;
>  }

[Severity: High]
Since pm_runtime_autosuspend() is called here, when the autosuspend timer
expires, the PM core executes the .runtime_suspend() callback directly
(xe_pci_runtime_suspend() -> xe_pm_runtime_suspend()), completely bypassing
.runtime_idle().

Because xe_pm_runtime_suspend() lacks the hardware idleness check, does this
allow the device to incorrectly suspend while GT force wake bits are still
set?

Should the idleness check also occur within the runtime_suspend callback to
safely reject a suspend and force a retry?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910215756.2393137-1-vinay.belgaumkar@intel.com?part=1

  parent reply	other threads:[~2026-09-10 22:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 21:57 [PATCH v3 1/2] drm/xe: Inspect all forcewake bits for runtime idleness Vinay Belgaumkar
2026-09-10 21:57 ` [PATCH v3 2/2] drm/xe: Poll GT for C6 before D3 Vinay Belgaumkar
2026-09-10 22:11   ` sashiko-bot
2026-09-10 22:14 ` sashiko-bot [this message]
2026-09-10 22:18 ` ✗ CI.checkpatch: warning for series starting with [v3,1/2] drm/xe: Inspect all forcewake bits for runtime idleness Patchwork
2026-09-10 22:20 ` ✓ CI.KUnit: success " Patchwork
2026-09-10 23:13 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-11  7:46 ` ✗ Xe.CI.FULL: failure " 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=20260910221449.E9E191F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vinay.belgaumkar@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