Re: [RFC PATCH] PM / Runtime: Allow to inactivate devices during system suspend

[Kevin Hilman <khilman@linaro.org>]

Alan Stern <stern@rowland.harvard.edu> writes:

> On Tue, 19 Nov 2013, Kevin Hilman wrote:
>
>> Alan Stern <stern@rowland.harvard.edu> writes:
>> 
>> > On Tue, 19 Nov 2013, Ulf Hansson wrote:
>> >
>> >> At the moment, system PM is already affecting behaviour of runtime PM
>> >> since it is preventing runtime suspend during system suspend.
>> >
>> > Sure.  And that behavior is documented.  In any case, it's a bug for 
>> > drivers to depend on runtime suspend for carrying out a system suspend.
>> 
>> As Rafael mentioned, there is bus/pm_domain code that comes into play
>> here, so I'm not sure it's always a bug.
>> 
>> IMO, it's not a bug for the driver to depend on runtime PM if the
>> bus/pm_domain is handling the details.
>> 
>> On OMAP, we handle all the SoC on-chip devices with a pm_domain since
>> the low-level PM operations that need to happen are bus-level things not
>> device-level things.  Therefore, drivers for these devices can rely
>> entirely on runtime PM, even for system suspend.  The late/early
>> callbacks in the pm_domain can see if the device is runtime suspended
>> already or not and behave accordingly.
>> 
>> So, this all *can* work by handling it at the bus/pm_domain level, but
>> as Ulf has mentioned (and I agree) it seems like a clunky workaround
>> because the PM core is preventing it from happening as one might expect.
>
> The problem is that userspace can disable runtime PM at any time by 
> writing "on" to /sys/.../power/control.  Once that's done, you can't
> depend on runtime PM to put the device into a low-power state during 
> system suspend.

We handle that too.

The way we handle it, that the pm_domain code "knows" that the device
*should* be runtime suspended by the time the pm_domain suspend_noirq
callback is called.  So it checks pm_runtime_status_suspended() and if
the device is not runtime suspended, the pm_domain will "forcibly"
runtime suspend the device (which just means, calling the driver's
->runtime_suspend(), doing the bus-level magic, and setting the runtime
PM state accordingly.)

This is arguably the same approach as the using the late callbacks that
you've already described, but it's just done in a hidden way at the bus
level.  Also, this solution predates the addtion of the late callbacks
and I believe may have even been initially proposed by you (or maybe
Rafael, I forgot.)

Kevin