public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Igor Stoppa <igor.stoppa@nokia.com>
To: ext Pavel Machek <pavel@ucw.cz>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [linux-pm] [RFC] sleepy linux
Date: Wed, 26 Dec 2007 22:09:59 +0200	[thread overview]
Message-ID: <1198699799.21629.13.camel@mort> (raw)
In-Reply-To: <20071225230731.GA29030@elf.ucw.cz>

Hi,
On Wed, 2007-12-26 at 00:07 +0100, ext Pavel Machek wrote:
> 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?
> 
> 
> 		Sleepy Linux
> 		~~~~~~~~~~~~
> 
> Copyright 2007 Pavel Machek <pavel@suse.cz>
> 	  GPLv2
> 
> Current Linux versions can enter suspend-to-RAM just fine, but only
> can do it on explicit request. But suspend-to-RAM is important, eating
> something like 10% of power needed for idle system. Starting suspend
> manually is not too convinient; it is not an option on multiuser
> machine, and even on single user machine, some things are not easy:
> 
> 1) Download this big chunk in mozilla, then go to sleep
> 
> 2) Compile this, then go to sleep

Why can't these cases be based on CPUIdle?

> 3) You can sleep now, but wake me up in 8:30 with mp3 player

This is about setting up properly the wakeup sources which means:

- the wakeup source is really capable of generating wakeups for the
target idle state

- the wakeup source is not actually capable of genrating wakeups from
the target idle state, which can be solved in 2 ways:

	- if the duration of the activity is known, set up an alarm 
	  (assuming alarms are proper wakeup sources) so that the
	   system is ready just in time, in a less efficient but more
	   responsive power saving state

	- if the duration of the activity is unknown choose the more 
	  efficient amongst the following solutions:

		- go to deep sleep state and periodically wakeup and
		  poll, with a period compatible with the timing 
		  of the event source

		- prevent too deep sleep states till the event happens

> Todays hardware is mostly capable of doing better: with correctly set
> up wakeups, machine can sleep and successfully pretend it is not
> sleeping -- by waking up whenever something interesting happens. Of
> course, it is easier on machines not connected to the network, and on
> notebook computers.

It might be that some hw doesn't provide deep power saving state for
some devices, but if the only missing feature is the wakeup capability,
it could be effectively replaced by some HW timer.


> Requirements:
> 
> 0) Working suspend-to-RAM, with kernel being able to bring video back.
> 
> 1) RTC clock that can wake up system
> 
> 2) Lid that can wake up a system,
>    or keyboard that can wake up system and does not loose keypress
>    or special screensaver setup
> 
> 3) Network card that is either down
>    or can wake up system on any packet (and not loose too many packets)

These are just few system specific case, but if you start including USB
devices, the situation is going to get quite complicated very soon, if
you explicitly include certain HW devices in your model.


-- 
Cheers, Igor

Igor Stoppa <igor.stoppa@nokia.com>
(Nokia Multimedia - CP - OSSO / Helsinki, Finland)

  parent reply	other threads:[~2007-12-26 20:09 UTC|newest]

Thread overview: 26+ 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 19:02   ` Pavel Machek
2007-12-26 20:17   ` Pavel Machek
2007-12-26 20:23     ` Oliver Neukum
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: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 ` Igor Stoppa [this message]
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=1198699799.21629.13.camel@mort \
    --to=igor.stoppa@nokia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    /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