[PATCH] drm/omap: force runtime PM suspend on system suspend

Tomi Valkeinen tomi.valkeinen at ti.com
Tue Jun 9 16:26:32 UTC 2020


On 09/06/2020 19:10, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen at ti.com> [200609 15:38]:
>> On 09/06/2020 18:12, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen at ti.com> [200609 10:33]:
>>>> Use suspend_late and resume_early callbacks in DSS submodules to force
>>>> runtime PM suspend and resume.
>>>>
>>>> We use suspend_late callback so that omapdrm's system suspend callback
>>>> is called first, as that will disable all the display outputs after
>>>> which it's safe to force DSS into suspend.
>>>
>>> I think we can avoid the pm_runtime_force use if we have omapdrm
>>> implement both .suspend and .suspend_late. In that case suspend would
>>> only disable the display outputs, then suspend_late would take care
>>> of switching off the lights and release the last PM runtime count
>>> after the children are done suspending.
>>
>> I'm not sure how that can be done cleanly. omapdrm doesn't really see the
>> DSS submodules. And even if it does, how can it "release the last PM runtime
>> count"? With pm_runtime_force_suspend for each? That would be almost the
>> same as this patch.
> 
> Well there should not be anything special needed for the children,
> it should all happen automatically for us.
> 
> I'm just wondering if this can be all done without the need for
> all the boilerplate code and adding suspend_late :)
> 
>> Also, if omapdrm can do the above, it could do it in the .suspend, after
>> disabling the display outputs. I don't think there's need for suspend_late
>> then.
> 
> Yeah so it seems. Can we just diconnect the display outputs
> in .prepare somewhere? Or is that the wrong place to do it?

Hmm, yes, perhaps... If omapdrm uses .prepare to disable all the outputs. Then DSS submodules could 
use UNIVERSAL_DEV_PM_OPS() and have the same functions for system and runtime suspend.

Although that has the problem that if the DSS is already runtime suspended when system suspend 
happens, the PM does not wake DSS up, and thus the suspend callbacks will crash if they access 
registers. So they need some extra logic there.

I'll see tomorrow if I can come up with something like that.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the dri-devel mailing list