selective wakeups
Hello,
I'm looking at how to support wakeup sources that resume a subset of the suspended devices. The goal is for the machine to be able to wakeup the CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic resume).
http://www.chromium.org/chromium-os/packages/power_manager/suspend-and-resume#TOC-Dark-Resume
My first idea is for userspace to be able to configure via sysfs which devices aren't going to be resumed when a given wakeup source fires. We'll also need a way to resume the display and sound card if there's user interaction when the system has resumed automatically.
Any comments?
Thanks,
Tomeu
Hi!
Quoted 6 lines
I'm looking at how to support wakeup sources that resume a subset of the suspended devices. The goal is for the machine to be able to wakeup the CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic resume).
Quoted 6 lines
http://www.chromium.org/chromium-os/packages/power_manager/suspend-and-resume#TOC-Dark-Resume
My first idea is for userspace to be able to configure via sysfs which devices aren't going to be resumed when a given wakeup source fires. We'll also need a way to resume the display and sound card if there's user interaction when the system has resumed automatically.
Well.. the web page describes quite different use case.
Anyway... right solution would be not to resume devices that were runtime-suspended, no? With that, additional sysfs tweaks should not be needed?
For the "periodically wakeup from S3 to prevent battery draining".. Some machines (Sharp Zaurus) already do similar tricks directly from kernel, and you may want to do the same. Battery completely draining when in S3 is quite bad situation, and preventing it even without userspace support would be good.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 7 lines · Tomeu Vizoso
Hello,
I'm looking at how to support wakeup sources that resume a subset of the suspended devices. The goal is for the machine to be able to wakeup the CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic resume).
That's a terrible name. Most resumes are automatic, in the sense that the computer carries out the resume automatically in response to some input.
A better name would be "partial resume".
Quoted 4 lines
http://www.chromium.org/chromium-os/packages/power_manager/suspend-and-resume#TOC-Dark-Resume
My first idea is for userspace to be able to configure via sysfs which devices aren't going to be resumed when a given wakeup source fires.
In general, the computer doesn't know which wakeup source has fired. ALl it knows is that it was asked to wake up.
Alan Stern
Quoted 8 lines · Tomeu Vizoso
I'm looking at how to support wakeup sources that resume a subset of the
suspended devices. The goal is for the machine to be able to wakeup the
CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic
resume).
Why the limitation? To stay in example, why wake the sound card if you have no sound to play even if the user initiated the wake up? Though in practice the problem with such attempts in the past was that it is very hard, in fact almost impossible, to find out what resumed a system. Secondly, you cannot assume that there's always a single cause for resuming.
Regards
Oliver
Quoted 9 lines · Oliver Neukum
Quoted 5 lines · Tomeu Vizoso
I'm looking at how to support wakeup sources that resume a subset of the suspended devices. The goal is for the machine to be able to wakeup the CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic resume).
Why the limitation? To stay in example, why wake the sound card if you have no sound to play even if the user initiated the wake up?
The point is to not wake it up if it isn't an user-initiated wake up. If it is, the existing behaviour is fine.
Quoted 3 lines
Though in practice the problem with such attempts in the past was that it is very hard, in fact almost impossible, to find out what resumed a system.
Yeah, I know it's not generally doable, but as Derek said, some HW allows for it.
Quoted 2 lines
Secondly, you cannot assume that there's always a single cause for resuming.
Are you thinking of the case in which the user opens the lid while we are waking up because of a RTC alarm? Userspace would realize the lid is open and would resume the screen.
Regards,
Tomeu
Quoted 3 lines
Regards Oliver
Quoted 8 lines · Tomeu Vizoso
Quoted 7 lines · Oliver Neukum
Quoted 5 lines · Tomeu Vizoso
I'm looking at how to support wakeup sources that resume a subset of the suspended devices. The goal is for the machine to be able to wakeup the CPU but not the display or sound card when the wakeup source isn't user-initiated, such as RTC or a network card (we can call it automatic resume).
Quoted 5 lines
Quoted 2 lines
Why the limitation? To stay in example, why wake the sound card if you have no sound to play even if the user initiated the wake up?
The point is to not wake it up if it isn't an user-initiated wake up. If it is, the existing behaviour is fine.
That was _your_ point. Oliver's point was different: Why not change the behavior also for user-initiated wakeups?
Quoted 7 lines
Quoted 3 lines
Though in practice the problem with such attempts in the past was that it is very hard, in fact almost impossible, to find out what resumed a system.
Yeah, I know it's not generally doable, but as Derek said, some HW allows for it.
Quoted 6 lines
Quoted 2 lines
Secondly, you cannot assume that there's always a single cause for resuming.
Are you thinking of the case in which the user opens the lid while we are waking up because of a RTC alarm? Userspace would realize the lid is open and would resume the screen.
In that case, why should the kernel bother resuming the screen when the wakeup cause is the user opening the lid (since userspace will resume the screen anyway)? In fact, why should the kernel bother resuming the screen ever?
Alan Stern