(Re-sending with correct mailing list addresses.)
Hi,
When the lid of a laptop is closed, certain devices can no longer
provide interesting input or will even produce bogus input, such as:
- input devices: touchscreen, touchpad, keyboard
- sensors: ambient light sensor, accelerometer, magnetometer
- a video camera mounted on the lid
- display backlight
Various workarounds cover some of these cases, and we have some ugly
hacks in ChromeOS to make things work. It would be nice if a userspace
power management daemon could listen to the lid-close event, and then
have a way to temporarily power off these devices, potentially through
sysfs.
I've been discussing this with Dmitry and Benson (cc'd), and we've been
wondering whether we could come up with a generic solution that could
benefit multiple device classes.
There's some overlap with runtime PM here. The action to be taken in
such a situation would probably be similar to a runtime suspend. The
match is not perfect though, since devices with more than two power
states might want to enter different states depending on the situation.
It's somewhat difficult to get the semantics right, since handles to
such devices might still be open. It might be easier to implement
behavior specific to device classes. On the other hand, it would be nice
to have a uniform way of shutting devices down, and not introduce
another possible path for a device to enter a power-saving state.
Rafael, can you give us your opinion on this?
Kind regards,
Patrik
On Tue, 2014-07-15 at 18:32 -0700, Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
<snip>
> It's somewhat difficult to get the semantics right, since handles to
> such devices might still be open. It might be easier to implement
> behavior specific to device classes. On the other hand, it would be nice
> to have a uniform way of shutting devices down, and not introduce
> another possible path for a device to enter a power-saving state.
>
> Rafael, can you give us your opinion on this?
Ditto the "tablet mode" of some devices such as the Thinkpad X41, or the
newer Lenovo Yoga, which should have their keyboards and touchpads
disabled.
If we used something like UPower to enable/disable those inaccessible
devices, we'd need a way of enumerating which devices won't be
accessible in those modes. Turning them off and back on should be easy
enough.
Cheers
On Tue, 15 Jul 2014, Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
>
> - input devices: touchscreen, touchpad, keyboard
Just to be clear: The laptop's internal keyboard can't be used, but
external keyboards can. The same goes for touchscreens and touchpads.
> - sensors: ambient light sensor, accelerometer, magnetometer
Why can't the accelerometer or magnetometer be used when the lid is
closed?
> - a video camera mounted on the lid
> - display backlight
I can think of one possible use for a video camera mounted inside the
lid. It's the modern analog of the age-old question: Does the
refrigerator light go out when the door is closed? Using the video
camera, users will be able to check whether the display backlight goes
out when the lid is closed. :-)
> Various workarounds cover some of these cases, and we have some ugly
> hacks in ChromeOS to make things work. It would be nice if a userspace
> power management daemon could listen to the lid-close event, and then
> have a way to temporarily power off these devices, potentially through
> sysfs.
Isn't it common for laptops to go into system suspend when the lid is
closed?
> I've been discussing this with Dmitry and Benson (cc'd), and we've been
> wondering whether we could come up with a generic solution that could
> benefit multiple device classes.
>
> There's some overlap with runtime PM here. The action to be taken in
> such a situation would probably be similar to a runtime suspend. The
> match is not perfect though, since devices with more than two power
> states might want to enter different states depending on the situation.
>
> It's somewhat difficult to get the semantics right, since handles to
> such devices might still be open. It might be easier to implement
> behavior specific to device classes. On the other hand, it would be nice
> to have a uniform way of shutting devices down, and not introduce
> another possible path for a device to enter a power-saving state.
What's the difference between shutting a device down and entering a
power-saving state? That is, why shouldn't the first be considered an
example of the second?
The general design of Linux's runtime PM is that the PM core tells
drivers when their devices are no longer being used, and it's up to the
driver to select an appropriate low-power state. That philosophy
doesn't fit well with the problem you want to solve, because you want
to turn off devices even when they _are_ still in use.
A separate sysfs interface might work out better.
Alan Stern
Hi Alan,
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern <[email protected]> wrote:
> On Tue, 15 Jul 2014, Patrik Fimml wrote:
>
>> (Re-sending with correct mailing list addresses.)
>>
>> Hi,
>>
>> When the lid of a laptop is closed, certain devices can no longer
>> provide interesting input or will even produce bogus input, such as:
>>
>> - input devices: touchscreen, touchpad, keyboard
>
> Just to be clear: The laptop's internal keyboard can't be used, but
> external keyboards can. The same goes for touchscreens and touchpads.
Right, we are talking about internal keyboards here, although there
are other scenarios where userspace may want to inhibit certain
devices. I think the common pattern with phones is to disable
touchscreen while phone is held close to your ear to avoid accidental
gestures.
>
>> - sensors: ambient light sensor, accelerometer, magnetometer
>
> Why can't the accelerometer or magnetometer be used when the lid is
> closed?
It may or it may not, it depends on the application.
>
>> - a video camera mounted on the lid
>> - display backlight
>
> I can think of one possible use for a video camera mounted inside the
> lid. It's the modern analog of the age-old question: Does the
> refrigerator light go out when the door is closed? Using the video
> camera, users will be able to check whether the display backlight goes
> out when the lid is closed. :-)
;) The most common case though is not to use such device (or not
present it to user/upper layers). When you are about to start video
chat you do not want to have your integrated camera be first in the
list of devices to be used when your lid is closed.
>
>> Various workarounds cover some of these cases, and we have some ugly
>> hacks in ChromeOS to make things work. It would be nice if a userspace
>> power management daemon could listen to the lid-close event, and then
>> have a way to temporarily power off these devices, potentially through
>> sysfs.
>
> Isn't it common for laptops to go into system suspend when the lid is
> closed?
Not necessarily, depends on user/policy and that is what we want
userspace to be able to define. I'd say we expect laptop to go to
system suspend when you close lid while undocked. If laptop is docked
then I just want to shut off screen and make my external monitor
primary one.
>
>> I've been discussing this with Dmitry and Benson (cc'd), and we've been
>> wondering whether we could come up with a generic solution that could
>> benefit multiple device classes.
>>
>> There's some overlap with runtime PM here. The action to be taken in
>> such a situation would probably be similar to a runtime suspend. The
>> match is not perfect though, since devices with more than two power
>> states might want to enter different states depending on the situation.
>>
>> It's somewhat difficult to get the semantics right, since handles to
>> such devices might still be open. It might be easier to implement
>> behavior specific to device classes. On the other hand, it would be nice
>> to have a uniform way of shutting devices down, and not introduce
>> another possible path for a device to enter a power-saving state.
>
> What's the difference between shutting a device down and entering a
> power-saving state? That is, why shouldn't the first be considered an
> example of the second?
>
> The general design of Linux's runtime PM is that the PM core tells
> drivers when their devices are no longer being used, and it's up to the
> driver to select an appropriate low-power state. That philosophy
> doesn't fit well with the problem you want to solve, because you want
> to turn off devices even when they _are_ still in use.
This does not sound quite right to me. We can tell PM core when
devices absolutely can not go to low power mode, but certain devices
can go into lower power state and wake up themselves even if there are
users: i.e. mice and keyboards with autosuspend. I guess it depends
what you define as being "in use".
>
> A separate sysfs interface might work out better.
>
I am not so much concerned about userspace, but about reusing of as
much of existing PM framework in the drivers. Right now it is very
hard to correctly track dependencies between general open/close,
system suspend/resume, and various runtime-PM transitions. Adding yet
another PM mechanism into the mix will just add more complexity.
Thanks,
Dmitry
On Wed, Jul 16, 2014 at 7:17 AM, Alan Stern <[email protected]> wrote:
>> Various workarounds cover some of these cases, and we have some ugly
>> hacks in ChromeOS to make things work. It would be nice if a userspace
>> power management daemon could listen to the lid-close event, and then
>> have a way to temporarily power off these devices, potentially through
>> sysfs.
>
> Isn't it common for laptops to go into system suspend when the lid is
> closed?
It's common, but it does not cover all possible cases. As was
mentioned by Dmitry, the user may dock his laptop, close his lid and
use external display, keyboard, and mouse. In that case, the internal
devices should be disabled or else they may send bogus input when the
laptop's B panel couples with the touchpad, for example.
Even in the case where system suspend happens, we don't want to depend
on that state change to disable these devices. It may take some time
before the system enters suspend, and in the meantime the input
devices with the lid closed may inadvertently cancel suspend by
generating a pm_wakeup_event(), which is not what we want.
Other scenarios outside of lid close where such a feature would be
helpful would be for transforming form-factors such as Yoga style
laptops where the screen can fold back into tablet mode, and the C
panel touchpad and keyboard should be disabled.
--
Benson Leung
Software Engineer, Chrom* OS
[email protected]
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > The general design of Linux's runtime PM is that the PM core tells
> > drivers when their devices are no longer being used, and it's up to the
> > driver to select an appropriate low-power state. That philosophy
> > doesn't fit well with the problem you want to solve, because you want
> > to turn off devices even when they _are_ still in use.
>
> This does not sound quite right to me. We can tell PM core when
> devices absolutely can not go to low power mode, but certain devices
> can go into lower power state and wake up themselves even if there are
> users: i.e. mice and keyboards with autosuspend. I guess it depends
> what you define as being "in use".
True. Right now the PM core relies on subsystems and drivers to tell
it when a device is or isn't in use.
> > A separate sysfs interface might work out better.
> >
>
> I am not so much concerned about userspace, but about reusing of as
> much of existing PM framework in the drivers. Right now it is very
> hard to correctly track dependencies between general open/close,
> system suspend/resume, and various runtime-PM transitions. Adding yet
> another PM mechanism into the mix will just add more complexity.
Would it make sense to unbind the drivers for these devices when the
lid is closed? With the drivers gone, there would naturally be no I/O
interactions with the hardware and the class devices would disappear.
The respective subsystems could then use their own runtime PM
mechanisms to power down the driverless devices. (Except for PCI,
unfortunately, which has a policy of leaving driverless devices at full
power. I was told this is a relic from the days before in-kernel mode
switching for displays was common, when user programs like the X server
would drive displays directly, without using a kernel driver.)
Alan Stern
On Wed, Jul 16, 2014 at 11:08 AM, Alan Stern <[email protected]> wrote:
>> I am not so much concerned about userspace, but about reusing of as
>> much of existing PM framework in the drivers. Right now it is very
>> hard to correctly track dependencies between general open/close,
>> system suspend/resume, and various runtime-PM transitions. Adding yet
>> another PM mechanism into the mix will just add more complexity.
>
> Would it make sense to unbind the drivers for these devices when the
> lid is closed? With the drivers gone, there would naturally be no I/O
> interactions with the hardware and the class devices would disappear.
FWIW, per your earlier recommendation[1], that is the approach that my
group has been using to disable various host controllers when Linux is
running (not suspended) but certain power-hungry peripherals are not
needed. It has mostly worked out OK; each driver typically implements
its own special PHY init/shutdown procedure, and calls into the common
clk_* functions to enable/disable the appropriate clocks.
Obviously the application needs to be able to cope with disappearing
devices, and you wouldn't want to have any filesystems mounted on top
of them when the unbind event happens.
Our devices are on an SoC's internal bus, not PCI.
[1] http://lists.linuxfoundation.org/pipermail/linux-pm/2012-April/033976.html
On Wed, 2014-07-16 at 14:08 -0400, Alan Stern wrote:
> > I am not so much concerned about userspace, but about reusing of as
> > much of existing PM framework in the drivers. Right now it is very
> > hard to correctly track dependencies between general open/close,
> > system suspend/resume, and various runtime-PM transitions. Adding
> yet
> > another PM mechanism into the mix will just add more complexity.
>
> Would it make sense to unbind the drivers for these devices when the
> lid is closed? With the drivers gone, there would naturally be no
No, because I don't want settings of my devices to disappear.
You can do that only for stateless devices. And I doubt you can
tell in general which devices are stateless.
Regards
Oliver
On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> (Re-sending with correct mailing list addresses.)
>
> Hi,
>
> When the lid of a laptop is closed, certain devices can no longer
> provide interesting input or will even produce bogus input, such as:
>
> - input devices: touchscreen, touchpad, keyboard
> - sensors: ambient light sensor, accelerometer, magnetometer
> - a video camera mounted on the lid
> - display backlight
>
> Various workarounds cover some of these cases, and we have some ugly
> hacks in ChromeOS to make things work. It would be nice if a userspace
> power management daemon could listen to the lid-close event, and then
> have a way to temporarily power off these devices, potentially through
> sysfs.
>
> I've been discussing this with Dmitry and Benson (cc'd), and we've been
> wondering whether we could come up with a generic solution that could
> benefit multiple device classes.
>
> There's some overlap with runtime PM here. The action to be taken in
> such a situation would probably be similar to a runtime suspend. The
> match is not perfect though, since devices with more than two power
> states might want to enter different states depending on the situation.
>
> It's somewhat difficult to get the semantics right, since handles to
> such devices might still be open. It might be easier to implement
> behavior specific to device classes. On the other hand, it would be nice
> to have a uniform way of shutting devices down, and not introduce
> another possible path for a device to enter a power-saving state.
>
> Rafael, can you give us your opinion on this?
Let me try to understand the scenario in the first place.
To start with, a number of devices is in use (that is, open, there are
applications listening/talking to them etc). Now, an event happens, such
as a laptop lid close and you want some of those devices, but possibly
not all of them, to quiesce themselves and go into low-power states.
Is that correct?
Rafael
On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > (Re-sending with correct mailing list addresses.)
> >
> > Hi,
> >
> > When the lid of a laptop is closed, certain devices can no longer
> > provide interesting input or will even produce bogus input, such as:
> >
> > - input devices: touchscreen, touchpad, keyboard
> > - sensors: ambient light sensor, accelerometer, magnetometer
> > - a video camera mounted on the lid
> > - display backlight
> >
> > Various workarounds cover some of these cases, and we have some ugly
> > hacks in ChromeOS to make things work. It would be nice if a userspace
> > power management daemon could listen to the lid-close event, and then
> > have a way to temporarily power off these devices, potentially through
> > sysfs.
> >
> > I've been discussing this with Dmitry and Benson (cc'd), and we've been
> > wondering whether we could come up with a generic solution that could
> > benefit multiple device classes.
> >
> > There's some overlap with runtime PM here. The action to be taken in
> > such a situation would probably be similar to a runtime suspend. The
> > match is not perfect though, since devices with more than two power
> > states might want to enter different states depending on the situation.
> >
> > It's somewhat difficult to get the semantics right, since handles to
> > such devices might still be open. It might be easier to implement
> > behavior specific to device classes. On the other hand, it would be nice
> > to have a uniform way of shutting devices down, and not introduce
> > another possible path for a device to enter a power-saving state.
> >
> > Rafael, can you give us your opinion on this?
>
> Let me try to understand the scenario in the first place.
>
> To start with, a number of devices is in use (that is, open, there are
> applications listening/talking to them etc). Now, an event happens, such
> as a laptop lid close and you want some of those devices, but possibly
> not all of them, to quiesce themselves and go into low-power states.
>
> Is that correct?
FWIW, I wouldn't build all this complication into the kernel, I would
expect:
- the kernel to make it easy to detect which of those devices are
internal to the machine
- make it easy to detect the state of the whole machine (for some
laptops like the Yoga, there's no SW_TABLET reporting)
- let well-behaved user-space handle the combined information (eg. it's
an internal device + lid is closed = shouldn't be used)
For input devices for example, I'd build this into gnome-settings-daemon
or gnome-shell directly, both of which have knowledge about input
devices used. I'd expect other desktop environments to do similar
things.
Applications can already check the lid status (through UPower), and with
the additional metadata from the kernel, know that the webcam won't be
usable when the lid is closed. Switching to external webcam, a webcam on
the outside of the case, or switch off the video stream would then be
the expected behaviour.
On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > > (Re-sending with correct mailing list addresses.)
> > >
> > > Hi,
> > >
> > > When the lid of a laptop is closed, certain devices can no longer
> > > provide interesting input or will even produce bogus input, such as:
> > >
> > > - input devices: touchscreen, touchpad, keyboard
> > > - sensors: ambient light sensor, accelerometer, magnetometer
> > > - a video camera mounted on the lid
> > > - display backlight
> > >
> > > Various workarounds cover some of these cases, and we have some ugly
> > > hacks in ChromeOS to make things work. It would be nice if a userspace
> > > power management daemon could listen to the lid-close event, and then
> > > have a way to temporarily power off these devices, potentially through
> > > sysfs.
> > >
> > > I've been discussing this with Dmitry and Benson (cc'd), and we've been
> > > wondering whether we could come up with a generic solution that could
> > > benefit multiple device classes.
> > >
> > > There's some overlap with runtime PM here. The action to be taken in
> > > such a situation would probably be similar to a runtime suspend. The
> > > match is not perfect though, since devices with more than two power
> > > states might want to enter different states depending on the situation.
> > >
> > > It's somewhat difficult to get the semantics right, since handles to
> > > such devices might still be open. It might be easier to implement
> > > behavior specific to device classes. On the other hand, it would be nice
> > > to have a uniform way of shutting devices down, and not introduce
> > > another possible path for a device to enter a power-saving state.
> > >
> > > Rafael, can you give us your opinion on this?
> >
> > Let me try to understand the scenario in the first place.
> >
> > To start with, a number of devices is in use (that is, open, there are
> > applications listening/talking to them etc). Now, an event happens, such
> > as a laptop lid close and you want some of those devices, but possibly
> > not all of them, to quiesce themselves and go into low-power states.
> >
> > Is that correct?
>
> FWIW, I wouldn't build all this complication into the kernel, I would
> expect:
> - the kernel to make it easy to detect which of those devices are
> internal to the machine
> - make it easy to detect the state of the whole machine (for some
> laptops like the Yoga, there's no SW_TABLET reporting)
> - let well-behaved user-space handle the combined information (eg. it's
> an internal device + lid is closed = shouldn't be used)
>
> For input devices for example, I'd build this into gnome-settings-daemon
> or gnome-shell directly, both of which have knowledge about input
> devices used. I'd expect other desktop environments to do similar
> things.
>
> Applications can already check the lid status (through UPower), and with
> the additional metadata from the kernel, know that the webcam won't be
> usable when the lid is closed. Switching to external webcam, a webcam on
> the outside of the case, or switch off the video stream would then be
> the expected behaviour.
Well, is the scenario I described correct or not? If not, then what
exactly is the scenario you want to be able to handle?
Rafael
On Thu, Jul 17, 2014 at 01:11:31AM +0200, Rafael J. Wysocki wrote:
> Let me try to understand the scenario in the first place.
>
> To start with, a number of devices is in use (that is, open, there are
> applications listening/talking to them etc). Now, an event happens, such
> as a laptop lid close and you want some of those devices, but possibly
> not all of them, to quiesce themselves and go into low-power states.
>
> Is that correct?
Yes, that is accurate.
The primary example is a laptop with an external monitor and mouse
attached which you're using with the lid closed. You want the mouse to
work, but input from the touchpad that might result from the lid being
close to it should be skipped. Also, the touchpad should enter a
low-power state.
We think that triggering this is probably best done in userspace, but
we would need a way of telling devices to quiesce themselves.
And as Oliver has pointed out, it might be desirable to preserve some
state/settings of devices. And it's probably undesirable to go through
the whole process of completely unregistering the device and then
probing/resetting/configuring it again.
Kind regards,
Patrik
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
> > > > (Re-sending with correct mailing list addresses.)
> > > >
> > > > Hi,
> > > >
> > > > When the lid of a laptop is closed, certain devices can no longer
> > > > provide interesting input or will even produce bogus input, such as:
> > > >
> > > > - input devices: touchscreen, touchpad, keyboard
> > > > - sensors: ambient light sensor, accelerometer, magnetometer
> > > > - a video camera mounted on the lid
> > > > - display backlight
> > > >
> > > > Various workarounds cover some of these cases, and we have some ugly
> > > > hacks in ChromeOS to make things work. It would be nice if a userspace
> > > > power management daemon could listen to the lid-close event, and then
> > > > have a way to temporarily power off these devices, potentially through
> > > > sysfs.
> > > >
> > > > I've been discussing this with Dmitry and Benson (cc'd), and we've been
> > > > wondering whether we could come up with a generic solution that could
> > > > benefit multiple device classes.
> > > >
> > > > There's some overlap with runtime PM here. The action to be taken in
> > > > such a situation would probably be similar to a runtime suspend. The
> > > > match is not perfect though, since devices with more than two power
> > > > states might want to enter different states depending on the situation.
> > > >
> > > > It's somewhat difficult to get the semantics right, since handles to
> > > > such devices might still be open. It might be easier to implement
> > > > behavior specific to device classes. On the other hand, it would be nice
> > > > to have a uniform way of shutting devices down, and not introduce
> > > > another possible path for a device to enter a power-saving state.
> > > >
> > > > Rafael, can you give us your opinion on this?
> > >
> > > Let me try to understand the scenario in the first place.
> > >
> > > To start with, a number of devices is in use (that is, open, there are
> > > applications listening/talking to them etc). Now, an event happens, such
> > > as a laptop lid close and you want some of those devices, but possibly
> > > not all of them, to quiesce themselves and go into low-power states.
> > >
> > > Is that correct?
<snip>
> Well, is the scenario I described correct or not? If not, then what
> exactly is the scenario you want to be able to handle?
I don't expect devices to have to know about the lid status, no. Patrik
might feel differently, but I think that all that's being asked is
already possible through existing user-space mechanisms, it's just
missing metadata to be able to implement it.
On Wed, Jul 16, 2014 at 4:23 PM, Bastien Nocera <[email protected]> wrote:
> On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
>> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
>> > On Thu, 2014-07-17 at 01:11 +0200, Rafael J. Wysocki wrote:
>> > > On Tuesday, July 15, 2014 06:32:06 PM Patrik Fimml wrote:
>> > > > (Re-sending with correct mailing list addresses.)
>> > > >
>> > > > Hi,
>> > > >
>> > > > When the lid of a laptop is closed, certain devices can no longer
>> > > > provide interesting input or will even produce bogus input, such as:
>> > > >
>> > > > - input devices: touchscreen, touchpad, keyboard
>> > > > - sensors: ambient light sensor, accelerometer, magnetometer
>> > > > - a video camera mounted on the lid
>> > > > - display backlight
>> > > >
>> > > > Various workarounds cover some of these cases, and we have some ugly
>> > > > hacks in ChromeOS to make things work. It would be nice if a userspace
>> > > > power management daemon could listen to the lid-close event, and then
>> > > > have a way to temporarily power off these devices, potentially through
>> > > > sysfs.
>> > > >
>> > > > I've been discussing this with Dmitry and Benson (cc'd), and we've been
>> > > > wondering whether we could come up with a generic solution that could
>> > > > benefit multiple device classes.
>> > > >
>> > > > There's some overlap with runtime PM here. The action to be taken in
>> > > > such a situation would probably be similar to a runtime suspend. The
>> > > > match is not perfect though, since devices with more than two power
>> > > > states might want to enter different states depending on the situation.
>> > > >
>> > > > It's somewhat difficult to get the semantics right, since handles to
>> > > > such devices might still be open. It might be easier to implement
>> > > > behavior specific to device classes. On the other hand, it would be nice
>> > > > to have a uniform way of shutting devices down, and not introduce
>> > > > another possible path for a device to enter a power-saving state.
>> > > >
>> > > > Rafael, can you give us your opinion on this?
>> > >
>> > > Let me try to understand the scenario in the first place.
>> > >
>> > > To start with, a number of devices is in use (that is, open, there are
>> > > applications listening/talking to them etc). Now, an event happens, such
>> > > as a laptop lid close and you want some of those devices, but possibly
>> > > not all of them, to quiesce themselves and go into low-power states.
>> > >
>> > > Is that correct?
Pretty much, although the devices would not listen to events
themselves but rather there will be an entity listening for various
events and requesting certain devices to quiesce themselves in
response for such events.
> <snip>
>> Well, is the scenario I described correct or not? If not, then what
>> exactly is the scenario you want to be able to handle?
>
> I don't expect devices to have to know about the lid status, no. Patrik
> might feel differently, but I think that all that's being asked is
> already possible through existing user-space mechanisms, it's just
> missing metadata to be able to implement it.
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.
Thanks,
Dmitry
On Thu, 2014-07-17 at 01:33 +0200, Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 01:13:42 AM Bastien Nocera wrote:
> > Applications can already check the lid status (through UPower), and with
> > the additional metadata from the kernel, know that the webcam won't be
> > usable when the lid is closed. Switching to external webcam, a webcam on
> > the outside of the case, or switch off the video stream would then be
> > the expected behaviour.
>
> Well, is the scenario I described correct or not? If not, then what
> exactly is the scenario you want to be able to handle?
Well, I think you need to add that you want user space to tell the
kernel that devices should not do remote wakeup under some conditions.
And I think this should not be limited to lid closure. And thus it
does not belong into the kernel.
A good example would be mice. From the kernel side runtime power
management works just fine. In practice it is rarely usable because
remote wakeup doesn't work well enough in common mice. It would
be good enough if the screen saver were working.
So I think lacking is the ability to model that remote wakeup
capabilities are
- dependent on external events
- binary capable or incapable
And we might introduce a system similar to rfkill that tells
devices that they are useless and hence idle due to external factors
(the internal webcam, keyboard, touchscreen ...)
Putting this into user space is difficult because you cannot really
fully close a keyboard.
Regards
Oliver
On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> 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.
What you're asking for is different from anything the PM subsystem has
done before. 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.
Alan Stern
On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > 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.
>
> What you're asking for is different from anything the PM subsystem has
> done before.
Right.
> 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.
Thanks,
Dmitry
On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > 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.
>
> >
> > What you're asking for is different from anything the PM subsystem has
> > done before.
>
> Right.
>
> > 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)
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.
Rafael
On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > > 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.
> >
> > > What you're asking for is different from anything the PM subsystem has
> > > done before.
> >
> > Right.
> >
> > > 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.
> 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.
Thanks,
Dmitry
On Thursday, July 17, 2014 05:43:42 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> > On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > > On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > > > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > > > 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.
> > >
> > > > What you're asking for is different from anything the PM subsystem has
> > > > done before.
> > >
> > > Right.
> > >
> > > > 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.
>
> > 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.
Rafael
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:
> > On Friday, July 18, 2014 02:43:02 AM Rafael J. Wysocki wrote:
> > > On Thursday, July 17, 2014 09:59:19 AM Dmitry Torokhov wrote:
> > > > On Thursday, July 17, 2014 10:39:16 AM Alan Stern wrote:
> > > > > On Wed, 16 Jul 2014, Dmitry Torokhov wrote:
> > > > > > 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.
> > > >
> > > > > What you're asking for is different from anything the PM subsystem has
> > > > > done before.
> > > >
> > > > Right.
> > > >
> > > > > 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.
> >
> > > 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
On Fri, 18 Jul 2014, Rafael J. Wysocki wrote:
> > > 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
On Fri, Jul 18, 2014 at 02:43:02AM +0200, Rafael J. Wysocki wrote:
> 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.
Can you give me some pointers?
> 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)
> 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.
Let me try to clear things up a little.
Of course, in most cases, a laptop would enter suspend after closing the
lid. But you can think of scenarios where the laptop would stay on:
- Your laptop is docked, and you use an external monitor, but you don't
want to have your laptop open (maybe due to lack of space).
- You have your laptop in your backpack and use it as a music player.
In those scenarios, you wouldn't want to see bogus input (our worst-case
example is the mouse pointer being over the 1-Click Buy button on
Amazon - stray clicks that result from the laptop lid interfering with
the touchpad wouldn't be a good thing).
Now there are basically two approaches with pros and cons:
1. Get userspace to close handles to all such devices while the lid is
closed, and
1a. Have drivers with sufficiently aggressive PM so that devices are
actually going to a low-power/off state when userspace doesn't have
any handles open.
This can be done with the infrastructure that we have in the kernel
today, although drivers might have to be improved in order to actually
get devices to power off.
2. Give userspace a way of quiescing a device. Handles to the device
stay open, but the device will no longer perform its function and,
if possible, power down.
For input devices, this makes a lot of sense in my opinion.
The notable difference to runtime PM as we have it today is that with
runtime PM, a device typically goes to a low-power state because it is
idle. In our scenario, we want to forcibly quiesce it even if it is not
idle (and if it continues to provide events in a low-power mode, we
want to ignore them instead of passing them on). So maybe integration
with runtime PM is not the best fit.
Perhaps the best way to go forward would be to add a new property for
all devices that support quiescing so userspace has a uniform way of
doing things, but have subsystems (and potentially the device driver)
decide what action is appropriate to quiesce a device. Some subsystems
might be able to provide a default implementation (e.g. input could just
skip all events that are reported from the device driver).
Regards,
Patrik
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> 2. Give userspace a way of quiescing a device. Handles to the device
> stay open, but the device will no longer perform its function and,
> if possible, power down.
"Quiescing" is the wrong word. "Quiescing a device" means stopping the
device from doing anything, which isn't what you want. You want to
ignore any activity the device may generate and reduce the device's
power consumption as much as possible. A better word would be
"deactivating".
> For input devices, this makes a lot of sense in my opinion.
I agree.
> The notable difference to runtime PM as we have it today is that with
> runtime PM, a device typically goes to a low-power state because it is
> idle. In our scenario, we want to forcibly quiesce it even if it is not
> idle (and if it continues to provide events in a low-power mode, we
> want to ignore them instead of passing them on). So maybe integration
> with runtime PM is not the best fit.
>
> Perhaps the best way to go forward would be to add a new property for
> all devices that support quiescing so userspace has a uniform way of
> doing things, but have subsystems (and potentially the device driver)
> decide what action is appropriate to quiesce a device. Some subsystems
> might be able to provide a default implementation (e.g. input could just
> skip all events that are reported from the device driver).
You mentioned that handles to the device would remain open. So when
the user opens the lid again, the old handles would start functioning,
right?
This has the disadvantage that the class device could not be
unregistered, because doing so would invalidate the open handles.
Under such circumestances, how would a userspace video program know not
to list a camera built into the lid among the possible video sources
(an example given earlier in this discussion)? The program would have
to make an explicit test of the "deactivate" property -- it wouldn't
automatically become aware that the camera wasn't available.
Would it sometimes be okay to unregister the class device and
invalidate the old handles, forcing programs to open new handles when
the lid is opened? This would reduce the number of changes user
programs would need.
Alan Stern
On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> device from doing anything, which isn't what you want. You want to
> ignore any activity the device may generate and reduce the device's
> power consumption as much as possible. A better word would be
> "deactivating".
Yeah, I agree that terminology is a bit tricky here, and we have some
words conveying a specific idea already ("suspend"). To me, deactivating
suggests a more permanent condition. FWIW, I've used "inhibit" in this
context before and think it captures the idea well, to add another
choice to the list.
> You mentioned that handles to the device would remain open. So when
> the user opens the lid again, the old handles would start functioning,
> right?
That's the idea, yes, and I think this would be desirable for the input
device class at least.
> This has the disadvantage that the class device could not be
> unregistered, because doing so would invalidate the open handles.
> Under such circumestances, how would a userspace video program know not
> to list a camera built into the lid among the possible video sources
> (an example given earlier in this discussion)? The program would have
> to make an explicit test of the "deactivate" property -- it wouldn't
> automatically become aware that the camera wasn't available.
>
> Would it sometimes be okay to unregister the class device and
> invalidate the old handles, forcing programs to open new handles when
> the lid is opened? This would reduce the number of changes user
> programs would need.
I guess we could potentially leave this for the device class to decide.
I'm not sure what the appropriate action for a video camera is anyway.
Should it go away completely, including its device? Should it be there,
but certainly not be the default choice when there is an external
camera? I'm thinking along the lines of some application's settings
dialog here, where it might be desirable to still be able to select the
internal camera for future recordings.
Of course, userspace could still decide simply not to
quiesce|deactivate|inhibit the device if that was desired.
Regards,
Patrik
On Fri, 18 Jul 2014, Patrik Fimml wrote:
> On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > device from doing anything, which isn't what you want. You want to
> > ignore any activity the device may generate and reduce the device's
> > power consumption as much as possible. A better word would be
> > "deactivating".
>
> Yeah, I agree that terminology is a bit tricky here, and we have some
> words conveying a specific idea already ("suspend"). To me, deactivating
> suggests a more permanent condition. FWIW, I've used "inhibit" in this
> context before and think it captures the idea well, to add another
> choice to the list.
Well, you can always reactivate a device after it has been deactivated.
But "inhibit" is good too.
> > You mentioned that handles to the device would remain open. So when
> > the user opens the lid again, the old handles would start functioning,
> > right?
>
> That's the idea, yes, and I think this would be desirable for the input
> device class at least.
For the input class, it may not matter. For example, the X server
should deal well with a touchpad that effectively gets hot-unplugged
and then hot-plugged later.
> > This has the disadvantage that the class device could not be
> > unregistered, because doing so would invalidate the open handles.
> > Under such circumestances, how would a userspace video program know not
> > to list a camera built into the lid among the possible video sources
> > (an example given earlier in this discussion)? The program would have
> > to make an explicit test of the "deactivate" property -- it wouldn't
> > automatically become aware that the camera wasn't available.
> >
> > Would it sometimes be okay to unregister the class device and
> > invalidate the old handles, forcing programs to open new handles when
> > the lid is opened? This would reduce the number of changes user
> > programs would need.
>
> I guess we could potentially leave this for the device class to decide.
Makes sense.
> I'm not sure what the appropriate action for a video camera is anyway.
> Should it go away completely, including its device? Should it be there,
> but certainly not be the default choice when there is an external
> camera? I'm thinking along the lines of some application's settings
> dialog here, where it might be desirable to still be able to select the
> internal camera for future recordings.
>
> Of course, userspace could still decide simply not to
> quiesce|deactivate|inhibit the device if that was desired.
There's some question about how much of userspace needs to get
involved. Just the daemon that manages these configuration changes, or
other programs as well? I guess that's not really our problem...
In the end, it sounds like you're suggesting a new pair of PM
callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
->uninhibit(). Plus an optional (?) sysfs interface for invoking the
callbacks.
Alan Stern
On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > "Quiescing" is the wrong word. "Quiescing a device" means stopping the
> > > device from doing anything, which isn't what you want. You want to
> > > ignore any activity the device may generate and reduce the device's
> > > power consumption as much as possible. A better word would be
> > > "deactivating".
> >
> > Yeah, I agree that terminology is a bit tricky here, and we have some
> > words conveying a specific idea already ("suspend"). To me, deactivating
> > suggests a more permanent condition. FWIW, I've used "inhibit" in this
> > context before and think it captures the idea well, to add another
> > choice to the list.
>
> Well, you can always reactivate a device after it has been deactivated.
> But "inhibit" is good too.
>
> > > You mentioned that handles to the device would remain open. So when
> > > the user opens the lid again, the old handles would start functioning,
> > > right?
> >
> > That's the idea, yes, and I think this would be desirable for the input
> > device class at least.
>
> For the input class, it may not matter. For example, the X server
> should deal well with a touchpad that effectively gets hot-unplugged
> and then hot-plugged later.
I thin kit would be nice if we could differentiate between unplugged
(physically gone) and disabled devices. If we shut off the touchpad does it
mean that user can't use UI to activate edge scrolling vs. two-finger
scrolling because our implementation made device to vanish?
>
> > > This has the disadvantage that the class device could not be
> > > unregistered, because doing so would invalidate the open handles.
> > > Under such circumestances, how would a userspace video program know not
> > > to list a camera built into the lid among the possible video sources
> > > (an example given earlier in this discussion)? The program would have
> > > to make an explicit test of the "deactivate" property -- it wouldn't
> > > automatically become aware that the camera wasn't available.
> > >
> > > Would it sometimes be okay to unregister the class device and
> > > invalidate the old handles, forcing programs to open new handles when
> > > the lid is opened? This would reduce the number of changes user
> > > programs would need.
> >
> > I guess we could potentially leave this for the device class to decide.
>
> Makes sense.
>
> > I'm not sure what the appropriate action for a video camera is anyway.
> > Should it go away completely, including its device? Should it be there,
> > but certainly not be the default choice when there is an external
> > camera? I'm thinking along the lines of some application's settings
> > dialog here, where it might be desirable to still be able to select the
> > internal camera for future recordings.
> >
> > Of course, userspace could still decide simply not to
> > quiesce|deactivate|inhibit the device if that was desired.
>
> There's some question about how much of userspace needs to get
> involved. Just the daemon that manages these configuration changes, or
> other programs as well? I guess that's not really our problem...
We need to provide means of implementing policy; the policy itself is not
really our concern ;)
>
> In the end, it sounds like you're suggesting a new pair of PM
> callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
> callbacks.
We do need sysfs interface so that userspace can talk to the devices in
question; and we also need to make sure that PM core is aware of the new
callbacks and provides guarantees about their interactions with system- and
runtime-PM callbacks so that individual drivers do not have to sort it out on
their own.
Thanks,
Dmitry
On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
[cut]
> > > I'm not sure what the appropriate action for a video camera is anyway.
> > > Should it go away completely, including its device? Should it be there,
> > > but certainly not be the default choice when there is an external
> > > camera? I'm thinking along the lines of some application's settings
> > > dialog here, where it might be desirable to still be able to select the
> > > internal camera for future recordings.
> > >
> > > Of course, userspace could still decide simply not to
> > > quiesce|deactivate|inhibit the device if that was desired.
> >
> > There's some question about how much of userspace needs to get
> > involved. Just the daemon that manages these configuration changes, or
> > other programs as well? I guess that's not really our problem...
>
> We need to provide means of implementing policy; the policy itself is not
> really our concern ;)
>
> >
> > In the end, it sounds like you're suggesting a new pair of PM
> > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
> > callbacks.
>
> We do need sysfs interface so that userspace can talk to the devices in
> question; and we also need to make sure that PM core is aware of the new
> callbacks and provides guarantees about their interactions with system- and
> runtime-PM callbacks so that individual drivers do not have to sort it out on
> their own.
A step back, please.
I have no idea why those need to be PM callbacks.
What you need really seems to be a way to tell a driver "ignore input from this
device from now on as it is most likely bogus". A natural reaction of the
driver to that might be to stop processing input from the device and then
runtime suspend it (and prevent it from generating remote wakeup as that may
be bogus as well), but I don't see why the PM core needs to be involved in
that at all.
Rafael
On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> [cut]
>
> > > > I'm not sure what the appropriate action for a video camera is anyway.
> > > > Should it go away completely, including its device? Should it be
> > > > there,
> > > > but certainly not be the default choice when there is an external
> > > > camera? I'm thinking along the lines of some application's settings
> > > > dialog here, where it might be desirable to still be able to select
> > > > the
> > > > internal camera for future recordings.
> > > >
> > > > Of course, userspace could still decide simply not to
> > > > quiesce|deactivate|inhibit the device if that was desired.
> > >
> > > There's some question about how much of userspace needs to get
> > > involved. Just the daemon that manages these configuration changes, or
> > > other programs as well? I guess that's not really our problem...
> >
> > We need to provide means of implementing policy; the policy itself is not
> > really our concern ;)
> >
> > > In the end, it sounds like you're suggesting a new pair of PM
> > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
> > > callbacks.
> >
> > We do need sysfs interface so that userspace can talk to the devices in
> > question; and we also need to make sure that PM core is aware of the new
> > callbacks and provides guarantees about their interactions with system-
> > and
> > runtime-PM callbacks so that individual drivers do not have to sort it out
> > on their own.
>
> A step back, please.
>
> I have no idea why those need to be PM callbacks.
>
> What you need really seems to be a way to tell a driver "ignore input from
> this device from now on as it is most likely bogus". A natural reaction of
> the driver to that might be to stop processing input from the device and
> then runtime suspend it (and prevent it from generating remote wakeup as
> that may be bogus as well), but I don't see why the PM core needs to be
> involved in that at all.
So that we do not need to handle cases like:
- I am already in idle state and request comes to inhibit, what do I do (in
driver) or:
- I inhibited the device, now system suspend comes, what do I do? Also what do
I do at resume? I'd rather not have driver checks host of flags to figure out
the end state if PM core could spell it out for me. We already have to sort
out open/close and suspend/resume iteractions (i.e what one needs to do to
suspend or resume device that has not been opened, and if it is different from
devices that have been opened).
Thanks,
Dmitry
On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > [cut]
> >
> > > > > I'm not sure what the appropriate action for a video camera is anyway.
> > > > > Should it go away completely, including its device? Should it be
> > > > > there,
> > > > > but certainly not be the default choice when there is an external
> > > > > camera? I'm thinking along the lines of some application's settings
> > > > > dialog here, where it might be desirable to still be able to select
> > > > > the
> > > > > internal camera for future recordings.
> > > > >
> > > > > Of course, userspace could still decide simply not to
> > > > > quiesce|deactivate|inhibit the device if that was desired.
> > > >
> > > > There's some question about how much of userspace needs to get
> > > > involved. Just the daemon that manages these configuration changes, or
> > > > other programs as well? I guess that's not really our problem...
> > >
> > > We need to provide means of implementing policy; the policy itself is not
> > > really our concern ;)
> > >
> > > > In the end, it sounds like you're suggesting a new pair of PM
> > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
> > > > callbacks.
> > >
> > > We do need sysfs interface so that userspace can talk to the devices in
> > > question; and we also need to make sure that PM core is aware of the new
> > > callbacks and provides guarantees about their interactions with system-
> > > and
> > > runtime-PM callbacks so that individual drivers do not have to sort it out
> > > on their own.
> >
> > A step back, please.
> >
> > I have no idea why those need to be PM callbacks.
> >
> > What you need really seems to be a way to tell a driver "ignore input from
> > this device from now on as it is most likely bogus". A natural reaction of
> > the driver to that might be to stop processing input from the device and
> > then runtime suspend it (and prevent it from generating remote wakeup as
> > that may be bogus as well), but I don't see why the PM core needs to be
> > involved in that at all.
>
> So that we do not need to handle cases like:
>
> - I am already in idle state and request comes to inhibit, what do I do (in
> driver) or:
I'm not sure why being "suspended" or not matters here. The PM core doesn't
know what physical state the device is in anyway and the driver or subsystem
(or another layer such as ACPI) has to track that.
Also it seems that it should be perfectly fine to ignore input from the device
without suspending it as well as it is perfectly fine to be suspended while
you are generally not ignoring the input (just because there is no input at
the moment, for example).
Yes, it make sense to suspend the device when you know you'll ignore input going
forward, but then if the real goal is to prevent bogus input from reaching
applications, then this isn't a power management problem even.
> - I inhibited the device, now system suspend comes, what do I do? Also what do
> I do at resume? I'd rather not have driver checks host of flags to figure out
> the end state if PM core could spell it out for me.
Well, how will the new PM callbacks help here, exactly?
> We already have to sort
> out open/close and suspend/resume iteractions (i.e what one needs to do to
> suspend or resume device that has not been opened, and if it is different from
> devices that have been opened).
I guess it would help if you gave an example.
Rafael
On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > [cut]
> > >
> > > > > > I'm not sure what the appropriate action for a video camera is anyway.
> > > > > > Should it go away completely, including its device? Should it be
> > > > > > there,
> > > > > > but certainly not be the default choice when there is an external
> > > > > > camera? I'm thinking along the lines of some application's settings
> > > > > > dialog here, where it might be desirable to still be able to select
> > > > > > the
> > > > > > internal camera for future recordings.
> > > > > >
> > > > > > Of course, userspace could still decide simply not to
> > > > > > quiesce|deactivate|inhibit the device if that was desired.
> > > > >
> > > > > There's some question about how much of userspace needs to get
> > > > > involved. Just the daemon that manages these configuration changes, or
> > > > > other programs as well? I guess that's not really our problem...
> > > >
> > > > We need to provide means of implementing policy; the policy itself is not
> > > > really our concern ;)
> > > >
> > > > > In the end, it sounds like you're suggesting a new pair of PM
> > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking the
> > > > > callbacks.
> > > >
> > > > We do need sysfs interface so that userspace can talk to the devices in
> > > > question; and we also need to make sure that PM core is aware of the new
> > > > callbacks and provides guarantees about their interactions with system-
> > > > and
> > > > runtime-PM callbacks so that individual drivers do not have to sort it out
> > > > on their own.
> > >
> > > A step back, please.
> > >
> > > I have no idea why those need to be PM callbacks.
> > >
> > > What you need really seems to be a way to tell a driver "ignore input from
> > > this device from now on as it is most likely bogus". A natural reaction of
> > > the driver to that might be to stop processing input from the device and
> > > then runtime suspend it (and prevent it from generating remote wakeup as
> > > that may be bogus as well), but I don't see why the PM core needs to be
> > > involved in that at all.
> >
> > So that we do not need to handle cases like:
> >
> > - I am already in idle state and request comes to inhibit, what do I do (in
> > driver) or:
>
> I'm not sure why being "suspended" or not matters here. The PM core doesn't
> know what physical state the device is in anyway and the driver or subsystem
> (or another layer such as ACPI) has to track that.
>
> Also it seems that it should be perfectly fine to ignore input from the device
> without suspending it as well as it is perfectly fine to be suspended while
> you are generally not ignoring the input (just because there is no input at
> the moment, for example).
>
> Yes, it make sense to suspend the device when you know you'll ignore input going
> forward, but then if the real goal is to prevent bogus input from reaching
> applications, then this isn't a power management problem even.
The area where it must interact with power management is wakeup, both remote
wakeup at run time and wakeup from system suspend. In particular, there's the
question whether or not a device ignoring its input should be regarded as a
wakeup source.
Rafael
On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
> On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > > [cut]
> > > >
> > > > > > > I'm not sure what the appropriate action for a video camera is
> > > > > > > anyway.
> > > > > > > Should it go away completely, including its device? Should it be
> > > > > > > there,
> > > > > > > but certainly not be the default choice when there is an
> > > > > > > external
> > > > > > > camera? I'm thinking along the lines of some application's
> > > > > > > settings
> > > > > > > dialog here, where it might be desirable to still be able to
> > > > > > > select
> > > > > > > the
> > > > > > > internal camera for future recordings.
> > > > > > >
> > > > > > > Of course, userspace could still decide simply not to
> > > > > > > quiesce|deactivate|inhibit the device if that was desired.
> > > > > >
> > > > > > There's some question about how much of userspace needs to get
> > > > > > involved. Just the daemon that manages these configuration
> > > > > > changes, or
> > > > > > other programs as well? I guess that's not really our problem...
> > > > >
> > > > > We need to provide means of implementing policy; the policy itself
> > > > > is not
> > > > > really our concern ;)
> > > > >
> > > > > > In the end, it sounds like you're suggesting a new pair of PM
> > > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking
> > > > > > the
> > > > > > callbacks.
> > > > >
> > > > > We do need sysfs interface so that userspace can talk to the devices
> > > > > in
> > > > > question; and we also need to make sure that PM core is aware of the
> > > > > new
> > > > > callbacks and provides guarantees about their interactions with
> > > > > system-
> > > > > and
> > > > > runtime-PM callbacks so that individual drivers do not have to sort
> > > > > it out
> > > > > on their own.
> > > >
> > > > A step back, please.
> > > >
> > > > I have no idea why those need to be PM callbacks.
> > > >
> > > > What you need really seems to be a way to tell a driver "ignore input
> > > > from
> > > > this device from now on as it is most likely bogus". A natural
> > > > reaction of
> > > > the driver to that might be to stop processing input from the device
> > > > and
> > > > then runtime suspend it (and prevent it from generating remote wakeup
> > > > as
> > > > that may be bogus as well), but I don't see why the PM core needs to
> > > > be
> > > > involved in that at all.
> > >
> > > So that we do not need to handle cases like:
> > >
> > > - I am already in idle state and request comes to inhibit, what do I do
> > > (in
> >
> > > driver) or:
> > I'm not sure why being "suspended" or not matters here. The PM core
> > doesn't know what physical state the device is in anyway and the driver
> > or subsystem (or another layer such as ACPI) has to track that.
> >
> > Also it seems that it should be perfectly fine to ignore input from the
> > device without suspending it as well as it is perfectly fine to be
> > suspended while you are generally not ignoring the input (just because
> > there is no input at the moment, for example).
> >
> > Yes, it make sense to suspend the device when you know you'll ignore input
> > going forward, but then if the real goal is to prevent bogus input from
> > reaching applications, then this isn't a power management problem even.
>
> The area where it must interact with power management is wakeup, both remote
> wakeup at run time and wakeup from system suspend. In particular, there's
> the question whether or not a device ignoring its input should be regarded
> as a wakeup source.
I'd say no.
Anyway, even though it is very tempting to declare inhibit a "deeper" state of
runtime suspend maybe you are right and inhibit should really be separate from
PM and drivers would have to sort out all the possible state permutations.
Considering input devices:
input_open(): check if device is inhibited, if so do nothing. Otherwise try
waking up itself and parent (via pm_runtime_get_sync() on itself), this will
power up the device. Do additional configuration if needed.
input_close(): check if device is inhibited, if not do pm_runtime_put (_sync?
to make sure we power off properly and not leave device up and running? or
should we power down manually not waiting for runtime PM)?
inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM
bring up the device. Do additional config if needed -> very similar to
input_open(), different condition.
runtime_suspend(): power down the device. If not inhibited enable as wakeup
source.
runtime_resume(): power up the device if device is opened and not inhibited.
system_suspend(): check if device is opened, not inhibited and not in
runtimesuspend already; power down.
system_resume(): power up the device if it is opened and not inhibited. I
guess it's OK to wake up device that shoudl be runtime-PM-idle since it will
go to back sleep shortly.
Ugh.. This is complicated...
Thanks,
Dmitry
On Friday, July 18, 2014 04:16:50 PM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 12:55:09 AM Rafael J. Wysocki wrote:
> > On Saturday, July 19, 2014 12:19:39 AM Rafael J. Wysocki wrote:
> > > On Friday, July 18, 2014 02:45:40 PM Dmitry Torokhov wrote:
> > > > On Friday, July 18, 2014 11:59:18 PM Rafael J. Wysocki wrote:
> > > > > On Friday, July 18, 2014 02:26:21 PM Dmitry Torokhov wrote:
> > > > > > On Friday, July 18, 2014 04:09:46 PM Alan Stern wrote:
> > > > > > > On Fri, 18 Jul 2014, Patrik Fimml wrote:
> > > > > > > > On Fri, Jul 18, 2014 at 03:00:46PM -0400, Alan Stern wrote:
> > > > > [cut]
> > > > >
> > > > > > > > I'm not sure what the appropriate action for a video camera is
> > > > > > > > anyway.
> > > > > > > > Should it go away completely, including its device? Should it be
> > > > > > > > there,
> > > > > > > > but certainly not be the default choice when there is an
> > > > > > > > external
> > > > > > > > camera? I'm thinking along the lines of some application's
> > > > > > > > settings
> > > > > > > > dialog here, where it might be desirable to still be able to
> > > > > > > > select
> > > > > > > > the
> > > > > > > > internal camera for future recordings.
> > > > > > > >
> > > > > > > > Of course, userspace could still decide simply not to
> > > > > > > > quiesce|deactivate|inhibit the device if that was desired.
> > > > > > >
> > > > > > > There's some question about how much of userspace needs to get
> > > > > > > involved. Just the daemon that manages these configuration
> > > > > > > changes, or
> > > > > > > other programs as well? I guess that's not really our problem...
> > > > > >
> > > > > > We need to provide means of implementing policy; the policy itself
> > > > > > is not
> > > > > > really our concern ;)
> > > > > >
> > > > > > > In the end, it sounds like you're suggesting a new pair of PM
> > > > > > > callbacks: ->deactivate() and ->reactivate(), or ->inhibit() and
> > > > > > > ->uninhibit(). Plus an optional (?) sysfs interface for invoking
> > > > > > > the
> > > > > > > callbacks.
> > > > > >
> > > > > > We do need sysfs interface so that userspace can talk to the devices
> > > > > > in
> > > > > > question; and we also need to make sure that PM core is aware of the
> > > > > > new
> > > > > > callbacks and provides guarantees about their interactions with
> > > > > > system-
> > > > > > and
> > > > > > runtime-PM callbacks so that individual drivers do not have to sort
> > > > > > it out
> > > > > > on their own.
> > > > >
> > > > > A step back, please.
> > > > >
> > > > > I have no idea why those need to be PM callbacks.
> > > > >
> > > > > What you need really seems to be a way to tell a driver "ignore input
> > > > > from
> > > > > this device from now on as it is most likely bogus". A natural
> > > > > reaction of
> > > > > the driver to that might be to stop processing input from the device
> > > > > and
> > > > > then runtime suspend it (and prevent it from generating remote wakeup
> > > > > as
> > > > > that may be bogus as well), but I don't see why the PM core needs to
> > > > > be
> > > > > involved in that at all.
> > > >
> > > > So that we do not need to handle cases like:
> > > >
> > > > - I am already in idle state and request comes to inhibit, what do I do
> > > > (in
> > >
> > > > driver) or:
> > > I'm not sure why being "suspended" or not matters here. The PM core
> > > doesn't know what physical state the device is in anyway and the driver
> > > or subsystem (or another layer such as ACPI) has to track that.
> > >
> > > Also it seems that it should be perfectly fine to ignore input from the
> > > device without suspending it as well as it is perfectly fine to be
> > > suspended while you are generally not ignoring the input (just because
> > > there is no input at the moment, for example).
> > >
> > > Yes, it make sense to suspend the device when you know you'll ignore input
> > > going forward, but then if the real goal is to prevent bogus input from
> > > reaching applications, then this isn't a power management problem even.
> >
> > The area where it must interact with power management is wakeup, both remote
> > wakeup at run time and wakeup from system suspend. In particular, there's
> > the question whether or not a device ignoring its input should be regarded
> > as a wakeup source.
>
> I'd say no.
>
> Anyway, even though it is very tempting to declare inhibit a "deeper" state of
> runtime suspend maybe you are right and inhibit should really be separate from
> PM and drivers would have to sort out all the possible state permutations.
>
> Considering input devices:
>
> input_open(): check if device is inhibited, if so do nothing. Otherwise try
> waking up itself and parent (via pm_runtime_get_sync() on itself), this will
> power up the device. Do additional configuration if needed.
>
> input_close(): check if device is inhibited, if not do pm_runtime_put (_sync?
> to make sure we power off properly and not leave device up and running? or
> should we power down manually not waiting for runtime PM)?
pm_runtime_put_sync() should be sufficient here I think.
> inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
>
> uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM
> bring up the device. Do additional config if needed -> very similar to
> input_open(), different condition.
>
> runtime_suspend(): power down the device. If not inhibited enable as wakeup
> source.
User space may not want it to be a wakeup source even if not inhibited
(it may not want it to wake up from system suspend, for example, like I do
with my cordless mouse).
> runtime_resume(): power up the device if device is opened and not inhibited.
>
> system_suspend(): check if device is opened, not inhibited and not in
> runtimesuspend already; power down.
I think you only need to know if the device has been powered down already
here regardless of the reason.
> system_resume(): power up the device if it is opened and not inhibited. I
> guess it's OK to wake up device that shoudl be runtime-PM-idle since it will
> go to back sleep shortly.
>
> Ugh.. This is complicated...
If runtime PM and system suspend shared the status, we might simplify this
somewhat. Problem is, there are drivers that don't support runtime PM, but
support system suspend.
Rafael
On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
> > The area where it must interact with power management is wakeup, both remote
> > wakeup at run time and wakeup from system suspend. In particular, there's
> > the question whether or not a device ignoring its input should be regarded
> > as a wakeup source.
>
> I'd say no.
This raises an interesting question. Suppose the system gets suspended
while the lid is closed. At that point, shouldn't wakeup devices be
enabled, even if they were already inhibited?
Alan Stern
On Sat, Jul 19, 2014 at 7:51 AM, Alan Stern <[email protected]> wrote:
> On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
>
>> > The area where it must interact with power management is wakeup, both remote
>> > wakeup at run time and wakeup from system suspend. In particular, there's
>> > the question whether or not a device ignoring its input should be regarded
>> > as a wakeup source.
>>
>> I'd say no.
>
> This raises an interesting question. Suppose the system gets suspended
> while the lid is closed. At that point, shouldn't wakeup devices be
> enabled, even if they were already inhibited?
It's possible that this could be a policy decision, ie, whether
power/wakeup is set to enabled for those devices or not.
However, I'd say that there's only one policy that makes sense in that
case : wakeups should be disabled while suspended.
If we inhibited the device during runtime to prevent stray input
events from being generated, it wouldn't make sense to allow the
device to potentially generate an accidental wakeup while suspended.
On Sat, 19 Jul 2014, Benson Leung wrote:
> > This raises an interesting question. Suppose the system gets suspended
> > while the lid is closed. At that point, shouldn't wakeup devices be
> > enabled, even if they were already inhibited?
>
> It's possible that this could be a policy decision, ie, whether
> power/wakeup is set to enabled for those devices or not.
> However, I'd say that there's only one policy that makes sense in that
> case : wakeups should be disabled while suspended.
>
> If we inhibited the device during runtime to prevent stray input
> events from being generated, it wouldn't make sense to allow the
> device to potentially generate an accidental wakeup while suspended.
That doesn't really make sense. If you're afraid of a device
generating spurious wakeup events when the lid is closed, you should
never enable it for wakeup. After all, one of the first things that
people often do after suspending their laptop is close the lid.
Alan Stern
On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> On Sat, 19 Jul 2014, Benson Leung wrote:
> > > This raises an interesting question. Suppose the system gets suspended
> > > while the lid is closed. At that point, shouldn't wakeup devices be
> > > enabled, even if they were already inhibited?
> >
> > It's possible that this could be a policy decision, ie, whether
> > power/wakeup is set to enabled for those devices or not.
> > However, I'd say that there's only one policy that makes sense in that
> > case : wakeups should be disabled while suspended.
> >
> > If we inhibited the device during runtime to prevent stray input
> > events from being generated, it wouldn't make sense to allow the
> > device to potentially generate an accidental wakeup while suspended.
>
> That doesn't really make sense. If you're afraid of a device
> generating spurious wakeup events when the lid is closed, you should
> never enable it for wakeup. After all, one of the first things that
> people often do after suspending their laptop is close the lid.
That's a fair point, and I think should be done by default. But that does not
change what Benson said - I think if we inhibited the device it should stay
inhibited across system suspend, including being disabled as wakeup source
even if it could be enabled as such.
Thanks,
Dmitry
On Saturday, July 19, 2014 11:21:52 AM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> > On Sat, 19 Jul 2014, Benson Leung wrote:
> > > > This raises an interesting question. Suppose the system gets suspended
> > > > while the lid is closed. At that point, shouldn't wakeup devices be
> > > > enabled, even if they were already inhibited?
> > >
> > > It's possible that this could be a policy decision, ie, whether
> > > power/wakeup is set to enabled for those devices or not.
> > > However, I'd say that there's only one policy that makes sense in that
> > > case : wakeups should be disabled while suspended.
> > >
> > > If we inhibited the device during runtime to prevent stray input
> > > events from being generated, it wouldn't make sense to allow the
> > > device to potentially generate an accidental wakeup while suspended.
> >
> > That doesn't really make sense. If you're afraid of a device
> > generating spurious wakeup events when the lid is closed, you should
> > never enable it for wakeup. After all, one of the first things that
> > people often do after suspending their laptop is close the lid.
>
> That's a fair point, and I think should be done by default. But that does not
> change what Benson said - I think if we inhibited the device it should stay
> inhibited across system suspend, including being disabled as wakeup source
> even if it could be enabled as such.
This seems to be the best approach to me too.
Rafael
On 2014-07-19 01:16, Dmitry Torokhov wrote:
<snip>
> I'd say no.
>
> Anyway, even though it is very tempting to declare inhibit a "deeper"
> state of
> runtime suspend maybe you are right and inhibit should really be
> separate from
> PM and drivers would have to sort out all the possible state
> permutations.
>
> Considering input devices:
>
> input_open(): check if device is inhibited, if so do nothing. Otherwise
> try
> waking up itself and parent (via pm_runtime_get_sync() on itself), this
> will
> power up the device. Do additional configuration if needed.
>
> input_close(): check if device is inhibited, if not do pm_runtime_put
> (_sync?
> to make sure we power off properly and not leave device up and running?
> or
> should we power down manually not waiting for runtime PM)?
>
> inhibit(): check if device is opened, if opened do
> pm_runtime_put_sync().
>
> uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime
> PM
> bring up the device. Do additional config if needed -> very similar to
> input_open(), different condition.
>
> runtime_suspend(): power down the device. If not inhibited enable as
> wakeup
> source.
>
> runtime_resume(): power up the device if device is opened and not
> inhibited.
>
> system_suspend(): check if device is opened, not inhibited and not in
> runtimesuspend already; power down.
>
> system_resume(): power up the device if it is opened and not inhibited.
> I
> guess it's OK to wake up device that shoudl be runtime-PM-idle since it
> will
> go to back sleep shortly.
>
> Ugh.. This is complicated...
Seriously complicated. The compositor and/or X.org can handle most of
that for
input devices already. For the camera, you want the application to know
that
the device is present, but not usable, instead of making it vanish or
rendering
it unusable. And if you wanted to implement this in the kernel, even
with the aid
of a user-space daemon, you're still missing the most important part,
the device
tagging.
Once you've tagged the devices which would need to be left alone when
the lid is
closed, or the laptop is in tablet mode, see if the problem can be
solved within
user-space alone. I'm fairly certain it wouldn't take too long to fix
Xorg
or a state-of-the-art compositor to behave properly.
All I see right now is making it harder to write devices drivers with no
real benefits.
Cheers
(Note: Your email arrived here with lines wrapped in a hard-to-read way,
not sure where the problem lies.)
On Tue, Jul 22, 2014 at 01:23:14AM +0200, [email protected] wrote:
> On 2014-07-19 01:16, Dmitry Torokhov wrote:
> <snip>
> >I'd say no.
> >
> >Anyway, even though it is very tempting to declare inhibit a
> >"deeper" state of
> >runtime suspend maybe you are right and inhibit should really be
> >separate from
> >PM and drivers would have to sort out all the possible state
> >permutations.
> >
> >Considering input devices:
> >
> >input_open(): check if device is inhibited, if so do nothing.
> >Otherwise try
> >waking up itself and parent (via pm_runtime_get_sync() on itself),
> >this will
> >power up the device. Do additional configuration if needed.
> >
> >input_close(): check if device is inhibited, if not do
> >pm_runtime_put (_sync?
> >to make sure we power off properly and not leave device up and
> >running? or
> >should we power down manually not waiting for runtime PM)?
> >
> >inhibit(): check if device is opened, if opened do
> >pm_runtime_put_sync().
> >
> >uninhibit(): if device is opened do pm_runtime_get_sync(), let
> >runtime PM
> >bring up the device. Do additional config if needed -> very similar to
> >input_open(), different condition.
> >
> >runtime_suspend(): power down the device. If not inhibited enable
> >as wakeup
> >source.
> >
> >runtime_resume(): power up the device if device is opened and not
> >inhibited.
> >
> >system_suspend(): check if device is opened, not inhibited and not in
> >runtimesuspend already; power down.
> >
> >system_resume(): power up the device if it is opened and not
> >inhibited. I
> >guess it's OK to wake up device that shoudl be runtime-PM-idle
> >since it will
> >go to back sleep shortly.
> >
> >Ugh.. This is complicated...
>
> Seriously complicated. The compositor and/or X.org can handle most
> of that for
> input devices already. For the camera, you want the application to
> know that
> the device is present, but not usable, instead of making it vanish
> or rendering
> it unusable. And if you wanted to implement this in the kernel, even
> with the aid
> of a user-space daemon, you're still missing the most important
> part, the device
> tagging.
I agree that the behaviour for e.g. the camera is debatable. Our primary
concern is input devices for now, but we were trying to see whether such
a functionality might be desired for other device classes as well.
> Once you've tagged the devices which would need to be left alone
> when the lid is
> closed, or the laptop is in tablet mode, see if the problem can be
> solved within
> user-space alone. I'm fairly certain it wouldn't take too long to
> fix Xorg
> or a state-of-the-art compositor to behave properly.
This would not allow you to power down the touchscreen more than to a
"idle" state without further modifications to drivers.
We also want to make sure that the kernel ignores input from these
devices for S3 suspend, so that stray touch inputs do not abort a
suspend that is about to happen.
And also, I think Xorg is not necessarily the proper layer for this.
It's a bit theoretical, but: If there were other users of the input
device, they would also want to ignore the events.
> All I see right now is making it harder to write devices drivers
> with no real benefits.
I don't see this problem at all. Just like drivers don't have to
implement runtime PM, they wouldn't be required to implement inhibit()
and its counterpart. But if they do implement such functionality, we
give them a standard interface to expose it.
If we stick with the example of input devices, we can even have a simple
default implementation in the device class (skipping any generated
events) and bring the basic behaviour to unmodified drivers for free.
Even if you did not have the "inhibit" interface, if you wanted to power
down the touchscreen completely when it's not accessible, this would
require very similar driver modifications.
Regards,
Patrik
On Fri, Jul 18, 2014 at 04:16:50PM -0700, Dmitry Torokhov wrote:
> [...]
> Anyway, even though it is very tempting to declare inhibit a "deeper" state of
> runtime suspend maybe you are right and inhibit should really be separate from
> PM and drivers would have to sort out all the possible state permutations.
>
> Considering input devices:
>
> input_open(): check if device is inhibited, if so do nothing. Otherwise try
> waking up itself and parent (via pm_runtime_get_sync() on itself), this will
> power up the device. Do additional configuration if needed.
>
> input_close(): check if device is inhibited, if not do pm_runtime_put (_sync?
> to make sure we power off properly and not leave device up and running? or
> should we power down manually not waiting for runtime PM)?
>
> inhibit(): check if device is opened, if opened do pm_runtime_put_sync().
>
> uninhibit(): if device is opened do pm_runtime_get_sync(), let runtime PM
> bring up the device. Do additional config if needed -> very similar to
> input_open(), different condition.
>
> runtime_suspend(): power down the device. If not inhibited enable as wakeup
> source.
>
> runtime_resume(): power up the device if device is opened and not inhibited.
>
> system_suspend(): check if device is opened, not inhibited and not in
> runtimesuspend already; power down.
>
> system_resume(): power up the device if it is opened and not inhibited. I
> guess it's OK to wake up device that shoudl be runtime-PM-idle since it will
> go to back sleep shortly.
>
> Ugh.. This is complicated...
There might be more elegant ways to implement this. It might make sense
to factor out power transitions. One could have a function that derives
the appropriate power state given the circumstances (i.e.
suspend/inhibit/runtime suspend) and then performs the needed
transition. This is something one would have to see when actually
implementing this, I might experiment with this approach a bit.
Regards,
Patrik