Re: [PATCH 2/2] drm/xe/pm: skip BO eviction on iGPU for non-hibernation sleep

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [High] drm/xe: missing GT resume on xe_pm_runtime_suspend() error path
  [1]
--

commit 6e0e7a2f201b73b5b02bb232ce3a960f5bc33388
Author: Matthew Auld <matthew.auld@intel.com>

drm/xe/pm: skip BO eviction on iGPU for non-hibernation sleep

This commit distinguishes S4 hibernation from S2idle/S3 suspend and skips BO
eviction and pinned BO preparation on iGPU platforms when not hibernating.

> diff --git a/drivers/gpu/drm/xe/xe_pm.c b/drivers/gpu/drm/xe/xe_pm.c
> index f483b565d323f..63bcb4aef461b 100644
> --- a/drivers/gpu/drm/xe/xe_pm.c
> +++ b/drivers/gpu/drm/xe/xe_pm.c

[ ... ]

> @@ -193,10 +199,12 @@ int xe_pm_suspend(struct xe_device *xe)
>  
>  	xe_display_pm_suspend(xe);
>  
> -	/* FIXME: Super racey... */
> -	err = xe_bo_evict_all(xe);
> -	if (err)
> -		goto err_display;
> +	if (xe_pm_needs_bo_evict(xe, hibernate)) {
> +		/* FIXME: Super racey... */
> +		err = xe_bo_evict_all(xe);
> +		if (err)
> +			goto err_display;
> +	}
>  
>  	for_each_gt(gt, xe, id) {
>  		err = xe_gt_suspend(gt);

[Severity: High]
This problem wasn't introduced by this patch, but if a subsequent GT fails to
suspend in the for_each_gt() loop in xe_pm_suspend() or
xe_pm_runtime_suspend() [1], does the error path leave earlier GTs
suspended?

drivers/gpu/drm/xe/xe_pm.c:xe_pm_suspend() {
	...
	for_each_gt(gt, xe, id) {
		err = xe_gt_suspend(gt);
		if (err)
			goto err_display;
	}
	...
err_display:
	xe_display_pm_resume(xe);
	xe_pxp_pm_resume(xe->pxp);
err:
	drm_dbg(&xe->drm, "Device suspend failed %d\n", err);
	xe_pm_block_end_signalling();
	return err;
}

Neither err_display in xe_pm_suspend() nor out_resume in
xe_pm_runtime_suspend() resumes the GTs that already succeeded before the
failure.  When suspend is aborted, the PM core keeps the device active while
those GTs remain physically suspended, leading to timeouts and hardware hangs
on subsequent access.

[1] https://sashiko.dev/#/bug/linux-5b6a3fb9-c8f9-45a4-a04c-2bc0919df0d7

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-s4-opti-v1-0-5edaea2c6d31@intel.com?part=2