On 09/06/2020 18:19, Tony Lindgren wrote:
But there's an extra runtime PM reference (dev.power.usage_count) that seems
to come out of nowhere. So when omap_drm_suspend is finished, there's still
usage_count of 1, and dispc never suspends fully.
Hmm no idea about that. My guess is that there might be an issue that was
masked earlier with omap_device calling the child runtime_suspend.
Yes. It's how PM works. It calls pm_runtime_get_noresume() before starting the suspend of a device.
So I guess omapdrm's suspend has been broken all the time, but it was "fixed" by omap_device.
Currently I'm only able to rmmod -f omapdrm, not sure if these issues might
be related.
Hmm, I always use modules, and can unload omapdrm and drm fine. But there's a sequence that must be
followed. However, the sequence starts with unloading omapdrm... What behavior you see with rmmod?
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
