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

[Ulf Hansson <ulf.hansson@linaro.org>]

On 14 November 2013 16:59, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 14 Nov 2013, Ulf Hansson wrote:
>
>> > The reason for doing things the way they are is to avoid races between
>> > system PM callbacks and runtime PM callbacks.  We don't want to have a
>> > runtime_resume routine powering up a device at the same time as a
>> > suspend routine is powering it down.
>>
>> I believe I understand why the PM core prevent this. Some subsystems
>> and drivers depends on this behaviour, but I wonder if we should
>> consider this as common cases or more like special cases?
>>
>> For those drivers that potentially could rely on runtime PM (and it's
>> callbacks) to inactivate the device during system suspend, and thus
>> don't have issues with races you describe above, the current behaviour
>> in the PM core adds unnecessary complexity for these drivers to handle
>> system suspend.
>
> What unnecessary complexity?
>
> Bear in mind that drivers _cannot_ rely on runtime PM to inactivate a
> device during system suspend.  The user can always prevent a device
> from going into runtime suspend by writing "on" to the
> /sys/.../power/control file.

Good that you brought this up. From my point of view I think the sysfs
for runtime PM could be debated whether it should exist at all, at
least in it's current form.

Anyway, if userspace decides to prevent runtime_suspend, I guess it
will have take the consequences for it as well. :-)

>
>> Drivers/buses/power_domains that handles runtime PM enabled devices,
>> will, as you also have pointed out earlier, need to implement the
>> .suspend callback (suspend_late or suspend_noirq might work as well)
>> and the corresponding .resume callback. This just for the sake of
>> making sure all their runtime enabled devices gets fully inactivated
>> during system suspend.
>>
>> I wonder if we somehow should move the responsibility of preventing
>> "runtime suspend" as a part of the system suspend, down to the driver
>> to decide instead of the PM core?
>
> No, I don't think so.  It would mean that every driver's suspend
> routine would have to do a pm_runtime_get of some sort.  It's better to
> just leave the single runtime_get call in the PM core.

In the end I suppose what case that is most common should win. :-) At
the same time, we should go slowly forward and it is probably not
realistic to convert each and every driver in one go.

So as a way forward, I am thinking of a similar approach as you
suggested with the "generic" suspend_late. But instead add a new
runtime PM API, which intent is to let drivers to specify for PM core,
if it should care to prevent the runtime suspend from happen during
system system - or not. Could that work?

Kind regards
Ulf Hansson

>
> Alan Stern
>