Hi,
* Tony Lindgren tony@atomide.com [210503 10:45]:
- Tomi Valkeinen tomi.valkeinen@ideasonboard.com [210503 08:04]:
On 29/04/2021 07:46, Tony Lindgren wrote:
Decoupling the system suspend and resume from PM runtime calls for all the other dss components should still also be done IMO. But that can be done as a separate clean-up patches after we have fixed the $subject issue.
I don't think I still really understand why all this is needed. I mean, obviously things don't work correctly at the moment, so maybe this patch can be applied to fix the system suspend. But it just feels like a big hack (the current pm_runtime_force_suspend/resume work-around feels like a big hack too).
Well omapdrm is not handling the -EBUSY error during system resume.
Or rather something on the resume path is not handling and cannot handle -EBUSY. And sounds like the reason is..
Slightly off topic, but I just noticed that we're using runtime_put_sync for some reason. Found 0eaf9f52e94f756147dbfe1faf1f77a02378dbf9. I've been fighting with system suspend for a long time =).
I wonder if using non-sync version would remove the EBUSY problem...
Worth trying, but it will only help if the -EBUSY error from pm_runtime_put() is handled somewhere for a retry..
..the use of pm_runtime_put_sync() like you suggested. I did a quick test with the minimal change below and that works :) Seems like that's probably the best minimal fix for the -rc cycle.
Regards,
Tony
8< ---------------- diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c b/drivers/gpu/drm/omapdrm/dss/dispc.c --- a/drivers/gpu/drm/omapdrm/dss/dispc.c +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c @@ -664,7 +664,7 @@ void dispc_runtime_put(struct dispc_device *dispc)
DSSDBG("dispc_runtime_put\n");
- r = pm_runtime_put_sync(&dispc->pdev->dev); + r = pm_runtime_put(&dispc->pdev->dev); WARN_ON(r < 0 && r != -ENOSYS); }