On 24/11/16 14:03, Jyri Sarha wrote:

>> The suspend/resume you're talking there is the system suspend/resume.
>> That's quite different than the runtime suspend/resume, and they should
>> do very different things.
>>
>> The current system suspend/resume in tilcdc looks fine.
>>
> 
> I don't undestand the same mechanism could not be used for runtime
> resume. Why should it matter if we configure the previous drm atomic
> state after system suspend or simple LCDC power down suspend?

They are quite different things.

For example, you have display up and running. The user requests for
system suspend. System suspend callback is called in tilcdc. That
callback should turn off the displays etc.

Runtime PM suspend should not do anything like that, because it's called
when the driver says the IP is not used, which means the driver has
already turned off the displays etc.

So, for example, when the system suspend happens, tilcdc's system
suspend callback disables the displays by calling some functions. These
functions stop the HW, maybe do other cleanups, and then do
pm_runtime_put(). This then causes runtime PM suspend callback to be called.

And, of course, runtime PM suspend is called anytime the driver is not
using the HW, not only when system suspend happens.

So, system suspend is a high level thing, comes at any point of time
from the userspace. Runtime PM is a driver internal thing, comes from
the driver.

 Tomi