* selective wakeups
@ 2015-02-03 9:54 Tomeu Vizoso
2015-02-03 12:14 ` Pavel Machek
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Tomeu Vizoso @ 2015-02-03 9:54 UTC (permalink / raw)
To: linux-pm, Rafael J. Wysocki, Pavel Machek
Cc: Derek Basehore, Javier Martinez Canillas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: selective wakeups
2015-02-03 9:54 selective wakeups Tomeu Vizoso
@ 2015-02-03 12:14 ` Pavel Machek
2015-02-03 15:33 ` Alan Stern
2015-02-04 9:05 ` Oliver Neukum
2 siblings, 0 replies; 6+ messages in thread
From: Pavel Machek @ 2015-02-03 12:14 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-pm, Rafael J. Wysocki, Derek Basehore,
Javier Martinez Canillas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: selective wakeups
2015-02-03 9:54 selective wakeups Tomeu Vizoso
2015-02-03 12:14 ` Pavel Machek
@ 2015-02-03 15:33 ` Alan Stern
2015-02-04 9:05 ` Oliver Neukum
2 siblings, 0 replies; 6+ messages in thread
From: Alan Stern @ 2015-02-03 15:33 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-pm, Rafael J. Wysocki, Pavel Machek, Derek Basehore,
Javier Martinez Canillas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: selective wakeups
2015-02-03 9:54 selective wakeups Tomeu Vizoso
2015-02-03 12:14 ` Pavel Machek
2015-02-03 15:33 ` Alan Stern
@ 2015-02-04 9:05 ` Oliver Neukum
2015-02-09 9:48 ` Tomeu Vizoso
2 siblings, 1 reply; 6+ messages in thread
From: Oliver Neukum @ 2015-02-04 9:05 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: linux-pm, Rafael J. Wysocki, Pavel Machek, Derek Basehore,
Javier Martinez Canillas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: selective wakeups
2015-02-04 9:05 ` Oliver Neukum
@ 2015-02-09 9:48 ` Tomeu Vizoso
2015-02-09 15:45 ` Alan Stern
0 siblings, 1 reply; 6+ messages in thread
From: Tomeu Vizoso @ 2015-02-09 9:48 UTC (permalink / raw)
To: Oliver Neukum
Cc: linux-pm, Rafael J. Wysocki, Pavel Machek, Derek Basehore,
Javier Martinez Canillas
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: selective wakeups
2015-02-09 9:48 ` Tomeu Vizoso
@ 2015-02-09 15:45 ` Alan Stern
0 siblings, 0 replies; 6+ messages in thread
From: Alan Stern @ 2015-02-09 15:45 UTC (permalink / raw)
To: Tomeu Vizoso
Cc: Oliver Neukum, linux-pm, Rafael J. Wysocki, Pavel Machek,
Derek Basehore, Javier Martinez Canillas
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-02-09 15:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-03 9:54 selective wakeups Tomeu Vizoso
2015-02-03 12:14 ` Pavel Machek
2015-02-03 15:33 ` Alan Stern
2015-02-04 9:05 ` Oliver Neukum
2015-02-09 9:48 ` Tomeu Vizoso
2015-02-09 15:45 ` Alan Stern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).