On Friday, July 18, 2014 03:30:31 AM Rafael J. Wysocki wrote:

On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:

quoted

On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:

quoted

On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:

quoted

On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:

quoted

On Wed, 16 Jul 2014, Dmitry Torokhov wrote:

quoted

We are not planning on implementing the policy in kernel, that's
indeed task for userspace; but unless we bring in the heavy hammer of
forcibly unbinding drivers, we do not currently have universal
mechanism of quiescing devices.

We sort of do: the ->freeze() callback.  But it wasn't intended for
this kind of use; drivers may very well expect that userspace will
already be frozen when the callback runs.  Besides, ->freeze() is
supposed to quiesce devices without powering them down, whereas you
want to do both.

Right.

quoted

What you're asking for is different from anything the PM subsystem has
done before.

Right.

quoted

Given this fact, I don't see any alternatives to adding a
new API or repurposing an existing API.  Either one would be somewhat
painful.

For example, we could arrange to invoke ->suspend().  However, since
the circumstances would be unusual (userspace is still running,
->prepare() was not called beforehand, ->suspend_irq() won't be called
afterward), subsystems and drivers may very well react inappropriately.

I do not think anybody expects that drivers would not have to be modified
to support this functionality; I expect drivers would have to declare
themselves "queiscable" and therefore would assert that they will act
according to whatever rules we set up. I only want to make sure that this
new state is added to existing list of PM states rather than creating
completely new facility, so that driver authors have a chance to
understand PM state transitions that involve their driver.

If you're referring to runtime PM, it doesn't use "states".  It uses status
values (you can think of them as metastates) which are "active", "suspended"
or in-transit from one to the other.  There's no room for more of these in
the design, I'm afraid.

Moreover, .runtime_suspend() can only be called when the device is quiescent
already.  [That also applies to .suspend_late() and .suspend_irq() for
system suspend and the freezing of tasks is requisite for the .prepare()
and .suspend() callbacks (and the corresponding hibernation-related ones).]

From past discussions on similar topics it followed that there really was
no generic way for individual drivers to quiesce devices on demand as long
as user space was running.  Everything we could come up with was racy, this
way or another.  That is the reason for using the freezer during system
suspend.  In other words, if you want drivers to quiesce devices by force,
you need to quiesce user space by force to start with - for example by
freezing it.

For runtime PM, on the other hand, the underlying observation is that
drivers should be able to detect when devices are already quiescent and
initialize power transitions at those points.  It's role is to help with
that, but not with quiescing things.

That said, in the "laptop lid closed" scenario (assuming that the system is
not supposed to suspend in response to that, which in my opinion is the
best approach)

This is default approach that works for many, but not necessarily all  use 
cases. I believe docked with lid closed scenario was mentioned already.

quoted

the problem really seems to be that drivers are not
aggressive enough with starting PM transitions (using runtime PM) when they
see no activity.  Thus it seems that when the lid is closed, it'll be good
to switch the drivers into a "more aggressive runtime PM mode" in which
they will use any opportunity to start a power transition without worrying
about extra latencies resulting from that.  In that mode they should also
disable remote wakeup.  I think this should be sufficient to address the
use case at hand.

OK, so how do we let the drivers know that they should start being aggressive 
with PM and that they should disable remote wakeup? I'd rather not add 
subsystem-specific interface for this, that is why we are reaching out in the 
first place.

For disabling remote wakeup we have a PM QoS flag that I'm not entirely happy
with, so I guess we can replace it with something saner (I talked about that
with Alan during the last year's LinuxCon, but then didn't have the time to
get to that).

For the whole thing I guess we can add a sysfs attribute under devices/.../power
that will need to be exposed by drivers supporting that feature.  I'm not sure
how to call it, though.

Or we could add an "aggressive" value to the devices/.../power/control attribute,
but then it will be difficult for user space to verify whether or not it is
supported for the given device.

Rafael