From: Pavel Machek <pavel@ucw.cz>
To: Oliver Neukum <oliver@neukum.org>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] sleepy linux
Date: Wed, 26 Dec 2007 21:32:58 +0100 [thread overview]
Message-ID: <20071226203258.GE8094@elf.ucw.cz> (raw)
In-Reply-To: <200712262123.37152.oliver@neukum.org>
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote:
> Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek:
> > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote:
> > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:
> > > > Heute 00:07:31
> > > >
> > > > This is RFC. It does not even work for me... it sleeps but it will not
> > > > wake up, because SATA wakeup code is missing. Code attached for illustration.
> > > >
> > > > I wonder if this is the right approach? What is right interface to the
> > > > drivers?
> > >
> > > IMHO you are making to many special cases. The system can be "sleepy"
> > > if all devices can be runtime suspended and all CPUs are idle.
> >
> > Is there an easy way to tell if all the devices are runtime suspended?
>
> Do you really want to know whether they are suspended or whether they
> could be suspended?
If they are suspended.
My plan is: let the drivers autosuspend on their own. If I see all of
them are autosuspended, then it looks like great time to put whole
system into s2ram...
> > I guess I need to know from atomic context :-(.
>
> Urgh. suspend() must be able to sleep and can fail.
That's ok.
... I also don't need to call any suspend() routines, because all the
drivers are already suspended, right?
And yes, I want device activity to prevent s2ram. If user is burning
CD, machine should not sleep. If user is actively typing, machine
should not sleep. My vision is: screen saver tells kernel keyboard
need not be very responsive, at that point keyboard driver can
autosuspend the keyboard, and if that was the last device, whole
system sleeps.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Oliver Neukum <oliver@neukum.org>
Cc: kernel list <linux-kernel@vger.kernel.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [RFC] sleepy linux
Date: Wed, 26 Dec 2007 21:32:58 +0100 [thread overview]
Message-ID: <20071226203258.GE8094@elf.ucw.cz> (raw)
In-Reply-To: <200712262123.37152.oliver@neukum.org>
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote:
> Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek:
> > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote:
> > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:
> > > > Heute 00:07:31
> > > >
> > > > This is RFC. It does not even work for me... it sleeps but it will not
> > > > wake up, because SATA wakeup code is missing. Code attached for illustration.
> > > >
> > > > I wonder if this is the right approach? What is right interface to the
> > > > drivers?
> > >
> > > IMHO you are making to many special cases. The system can be "sleepy"
> > > if all devices can be runtime suspended and all CPUs are idle.
> >
> > Is there an easy way to tell if all the devices are runtime suspended?
>
> Do you really want to know whether they are suspended or whether they
> could be suspended?
If they are suspended.
My plan is: let the drivers autosuspend on their own. If I see all of
them are autosuspended, then it looks like great time to put whole
system into s2ram...
> > I guess I need to know from atomic context :-(.
>
> Urgh. suspend() must be able to sleep and can fail.
That's ok.
... I also don't need to call any suspend() routines, because all the
drivers are already suspended, right?
And yes, I want device activity to prevent s2ram. If user is burning
CD, machine should not sleep. If user is actively typing, machine
should not sleep. My vision is: screen saver tells kernel keyboard
need not be very responsive, at that point keyboard driver can
autosuspend the keyboard, and if that was the last device, whole
system sleeps.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2007-12-26 20:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-25 23:07 [RFC] sleepy linux Pavel Machek
2007-12-26 17:28 ` Oliver Neukum
2007-12-26 17:28 ` Oliver Neukum
2007-12-26 19:02 ` Pavel Machek
2007-12-26 19:02 ` Pavel Machek
2007-12-26 20:17 ` Pavel Machek
2007-12-26 20:17 ` Pavel Machek
2007-12-26 20:23 ` Oliver Neukum
2007-12-26 20:23 ` Oliver Neukum
2007-12-26 20:32 ` Pavel Machek [this message]
2007-12-26 20:32 ` Pavel Machek
2007-12-26 23:15 ` Oliver Neukum
2007-12-29 23:48 ` Pavel Machek
2007-12-27 9:41 ` Oliver Neukum
2007-12-29 23:51 ` Pavel Machek
2007-12-30 16:39 ` Oliver Neukum
2007-12-31 14:44 ` Pavel Machek
2008-01-02 10:52 ` Oliver Neukum
2007-12-26 18:56 ` H. Peter Anvin
2007-12-26 19:00 ` Pavel Machek
2007-12-26 19:22 ` H. Peter Anvin
2007-12-26 20:08 ` Oliver Neukum
2007-12-26 20:08 ` Oliver Neukum
2007-12-26 20:43 ` H. Peter Anvin
2007-12-26 20:51 ` Pavel Machek
2007-12-26 20:54 ` H. Peter Anvin
2007-12-29 23:44 ` Pavel Machek
2007-12-26 20:09 ` [linux-pm] " Igor Stoppa
2007-12-30 11:15 ` Ingo Molnar
2008-01-05 21:51 ` Pavel Machek
2008-01-08 16:37 ` Ingo Molnar
2008-01-08 19:15 ` Pavel Machek
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=20071226203258.GE8094@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=oliver@neukum.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.