* Tony Lindgren <tony@xxxxxxxxxxx> [210427 10:54]: > * Tony Lindgren <tony@xxxxxxxxxxx> [210427 10:12]: > > * Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> [210427 08:47]: > > > If I understand right, this is only an issue when the dss was not enabled > > > before the system suspend? And as the dispc is not enabled at suspend, > > > pm_runtime_force_suspend and pm_runtime_force_resume don't really do > > > anything. At resume, the DRM resume functionality causes omapdrm to call > > > pm_runtime_get and put, and this somehow causes the dss to stay enabled. > > > > We do have dss enabled at system suspend from omap_atomic_comit_tail() > > until pm_runtime_force_suspend(). Then we have pm_runtime_force_resume() > > enable it. > > Sorry I already forgot that pm_runtime_force_resume() is not enabling > it because pm_runtime_need_not_resume().. It's the omapdrm calling > pm_runtime_get() that enables the hardware on resume. > > > Then on resume PM runtime prevents disable of the hardware on resume path > > until after device_complete(). Until then we have rpm_suspend() return > > -EBUSY, and so the parent child_count is not going to get decreased. > > Something would have to handle the -EBUSY error here it seems. I sent out v2 patch with an updated description. Regards, Tony
