| Message ID | 20241011225906.3789965-1-adrian.larumbe@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] drm/panthor: Fix runtime suspend sequence after OPP transition error | expand |
On Fri, Oct 11, 2024 at 11:56:59PM +0100, Adrián Larumbe 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@collabora.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> for this patch. For the other two I would like first if we try to understand why the suspend does not happen quick enough (or at all). Best regards, Liviu > --- > 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); > + } > drm_dev_exit(cookie); > } > > -- > 2.46.2 >
On Fri, 11 Oct 2024 23:56:59 +0100 Adrián Larumbe <adrian.larumbe@collabora.com> 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@collabora.com> > --- > 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); > } >
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); + } drm_dev_exit(cookie); }
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@collabora.com> --- drivers/gpu/drm/panthor/panthor_device.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)