Thread (41 messages) 41 messages, 8 authors, 2014-07-28

Re: Power-managing devices that are not of interest at some point in time

From: Alan Stern <stern@rowland.harvard.edu>
Date: 2014-07-18 15:19:09
Also in: linux-pm, lkml

On Fri, 18 Jul 2014, Rafael J. Wysocki wrote:
quoted
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).
Right.  We discussed changing .../power/wakeup so that it could contain
"enabled", "disabled", or "off", where "off" would mean remote wakeup
should be disabled even during runtime suspend.
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.
"runtime_mode"?

Will this really be capable of doing what Dmitry wants?  I don't know
how the drivers in question work.  But if a driver increments the
runtime usage count each time the device file is opened, forcibly
setting the usage count back to 0 won't be easy.

Also, would putting the camera into runtime suspend prevent it from
showing up on a list of available video devices?  I doubt it.  More
likely, the video driver would have to unregister the class device
while remaining bound to the physical device.  Probably other drivers
would have to do the same sort of thing.  (I don't know whether doing
this would retain the settings as Oliver wants, though.)

Alan Stern
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help