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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/06/2020 19:10, Tony Lindgren wrote:
* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [200609 15:38]:
On 09/06/2020 18:12, Tony Lindgren wrote:
* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux