selective wakeups

selective wakeups

[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).

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

Re: selective wakeups

[Pavel Machek]

Hi!

> 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.

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: selective wakeups

[Alan Stern]

On Tue, 3 Feb 2015, Tomeu Vizoso wrote:

> 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".

> 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

Re: selective wakeups

[Oliver Neukum]

On Tue, 2015-02-03 at 10:54 +0100, Tomeu Vizoso wrote:
> 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

Re: selective wakeups

[Tomeu Vizoso]

On 02/04/2015 10:05 AM, Oliver Neukum wrote:
> On Tue, 2015-02-03 at 10:54 +0100, Tomeu Vizoso wrote:
>> 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.

> 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.

> 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

> Regards Oliver
> 
> 

Re: selective wakeups

[Alan Stern]

On Mon, 9 Feb 2015, Tomeu Vizoso wrote:

> On 02/04/2015 10:05 AM, Oliver Neukum wrote:
> > On Tue, 2015-02-03 at 10:54 +0100, Tomeu Vizoso wrote:
> >> 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.

That was _your_ point.  Oliver's point was different: Why not change
the behavior also for user-initiated wakeups?

> > 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.
> 
> > 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