On Fri, 11 Oct 2024 23:56:59 +0100
Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx> wrote:
> In case an OPP transition to a suspension state fails during the runtime
> PM suspend call, if the driver's subsystems were successfully resumed,
> we should return -EAGAIN so that the device's runtime PM status remains
> 'active'.
>
> If FW reload failed, then we should fall through, so that the PM core
> can flag the device as having suffered a runtime error.
>
> Signed-off-by: Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c b/drivers/gpu/drm/panthor/panthor_device.c
> index 4082c8f2951d..cedd3cbcb47d 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -528,8 +528,13 @@ int panthor_device_suspend(struct device *dev)
> drm_dev_enter(&ptdev->base, &cookie)) {
> panthor_gpu_resume(ptdev);
> panthor_mmu_resume(ptdev);
> - drm_WARN_ON(&ptdev->base, panthor_fw_resume(ptdev));
> - panthor_sched_resume(ptdev);
> + ret = panthor_fw_resume(ptdev);
> + if (!ret) {
> + panthor_sched_resume(ptdev);
> + ret = -EAGAIN;
> + } else {
> + drm_err(&ptdev->base, "FW resume failed at runtime suspend: %d\n", ret);
> + }
Hm, I'm not convinced resuming when devfreq_suspend() fails was the
right thing to do anyway. Can't we just assume the suspend succeeded in
that case, and force the devfreq OOP transition in the resume path, or
ignore it?
> drm_dev_exit(cookie);
> }
>
