Hi,
* Tony Lindgren <tony@xxxxxxxxxxx> [210503 10:45]:
> * Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> [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);
}
