From: Tomeu Vizoso <tomeu.vizoso@collabora.com>
To: Oliver Neukum <oliver@neukum.org>
Cc: linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>,
Derek Basehore <dbasehore@google.com>,
Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Subject: Re: selective wakeups
Date: Mon, 09 Feb 2015 10:48:23 +0100 [thread overview]
Message-ID: <54D88267.9060801@collabora.com> (raw)
In-Reply-To: <1423040716.19176.6.camel@linux-0dmf.site>
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
>
>
next prev parent reply other threads:[~2015-02-09 9:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2015-02-09 15:45 ` Alan Stern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D88267.9060801@collabora.com \
--to=tomeu.vizoso@collabora.com \
--cc=dbasehore@google.com \
--cc=javier.martinez@collabora.co.uk \
--cc=linux-pm@vger.kernel.org \
--cc=oliver@neukum.org \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).