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

["Belgaumkar, Vinay" <vinay.belgaumkar@intel.com>]

On 9/16/2026 12:24 PM, sashiko-bot@kernel.org wrote:
> 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.
Disabling power gating has no impact on C6. GT can enter C6 in spite of it.
>
>> +	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.
This has been discussed previously. The next pm ref get/put should 
re-arm and trigger the auto suspend timer.
>