Re: [PATCH v6] drm/xe: Poll GT for C6 before D3

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] drm/xe: C6 poll after xe_pm_runtime_suspend() always fails breaking D3
- [Medium] pm: device stuck in RPM_ACTIVE when C6 check fails
--

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

drm/xe: Poll GT for C6 before D3

This commit ensures the GT is in C6 before transitioning to D3 during
runtime suspend, avoiding scenarios where GT is accessed after D3 is
programmed. It aborts the suspend by returning an error if the GT
fails to enter C6.

> diff --git a/drivers/gpu/drm/xe/xe_pci.c b/drivers/gpu/drm/xe/xe_pci.c
> index 00b2b5dfb8f6c..d66d5a0339ae3 100644
> --- a/drivers/gpu/drm/xe/xe_pci.c
> +++ b/drivers/gpu/drm/xe/xe_pci.c

[ ... ]

> @@ -1394,6 +1394,17 @@ static int xe_pci_runtime_suspend(struct device *dev)
>  	if (err)
>  		return err;
>  
> +	err = xe_pm_wait_all_c6(xe);

[Severity: High]
Since this check happens after xe_pm_runtime_suspend(), which already
called xe_gt_suspend() and explicitly disabled power gating (RC6), isn't
this guaranteed to fail and cause 200ms timeouts on every suspend attempt?

When the system attempts to enter D3cold runtime suspend, GuC is already
reset and power gating is disabled by the time we reach this check, so
the GT cannot enter C6 autonomously.

> +	if (err) {
> +		drm_dbg(&xe->drm, "Resuming - GT C6 check failed!");
> +		ret = xe_pm_runtime_resume(xe);
> +		if (ret) {
> +			drm_err(&xe->drm, "Resume failed after suspend was canceled");
> +			return ret;
> +		}
> +		return err;

[Severity: Medium]
When we return -EAGAIN to the PM core here to abort the suspend, shouldn't
we first update the last_busy timestamp by calling
pm_runtime_mark_last_busy(dev)?

Without it, the PM core's rpm_suspend() handles -EAGAIN by aborting suspend
but only re-arms the autosuspend timer if last_busy was updated. This causes
the autosuspend expiration time to evaluate to the past, preventing the timer
from being re-armed and leaving the device awake indefinitely in RPM_ACTIVE
until another explicit PM cycle occurs.

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