From: David Brownell <david-b@pacbell.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>,
Ben Dooks <ben@simtec.co.uk>,
Dirk Behme <dirk.behme@de.bosch.com>,
linux-pm@lists.linux-foundation.org,
Johannes Berg <johannes@sipsolutions.net>,
Nicolas Pitre <nico@cam.org>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [PATCH] implement pm_ops.valid for everybody
Date: Wed, 21 Mar 2007 16:25:22 -0700 [thread overview]
Message-ID: <200703211625.23253.david-b@pacbell.net> (raw)
In-Reply-To: <20070321225730.GL6057@elf.ucw.cz>
[ removed crosspost to linux-arm, members-only ]
On Wednesday 21 March 2007 3:57 pm, Pavel Machek wrote:
> Hi!
>
> > > Which is very much an indication of how weak ACPI is. It
> > > doesn't contemplate typical SOC behavior, which have a wide
> > > variety of system sleep states that leave the CPU on ... and
> > > which may not even *have* (or need!) a "cpu off" state.
> > >
> > > My own definition would be more like: the minimal RAM-based
> > > power-saving system state is "standby". If the system
> > > implements a deeper RAM-based system sleep state, that's "STR".
> >
> > Hmmm, this leaves the decision how to call each state COMPLETELY to the
> > implementor, doesn't it?
Not really. Standby is not as deep a sleep state as STR, so it
would be wrong to have it save more power than STR.
And remember that the implementor must make various decisions in
any case, since the SOC probably has half a dozen distinct
low power states, but Linux can only name two of them.
> Is that a problem? If someone is clever enough to implement suspend, I
> think we can trust them to name their states right.
Modulo my earlier comment, showing that you **don't** need to be
especially clever to implement a "standby" on most systems ... !
> (And trust me, we can flame them if not).
>
> (Anyway, my definition would be "mem" == RAM is powered, everything
> else is down, except for devices needed for wakeup; "standby" ==
> something is powered that can be powered down, we'll fix that in next version).
That implies that standby is less desirable, and wouldn't be used much.
That's a false implication. Among other things, it may be more important
to have various wakeup event sources at moderate power, than to go
without them at lower power. Simple math: N hours at 75% power savings,
which lets the system become fully operational at any time; versus those
same hours at 0% power savings (full power), because STR (90% savings)
doesn't support some essential wakeup events.
Moreover, that assumes "powered" is the relevant issue, rather than for
example "clocked". As in: power is always applied everywhere, registers
are always preserved, but more clocks are gated off in deeper sleep states.
That "CPU and peripheral state is discarded" notion is NOT generally
applicable, so that it shouldn't be hard-coded into a definition of
what distinguishes the states given the "standby" and "mem" names.
- Dave
next prev parent reply other threads:[~2007-03-21 23:25 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070320015821.782406000@sipsolutions.net>
2007-03-20 1:58 ` [PATCH] rework pm_ops pm_disk_modes foo Johannes Berg
2007-03-20 8:46 ` [PATCH v2] " Johannes Berg
2007-03-20 9:31 ` Pavel Machek
2007-03-20 9:36 ` Johannes Berg
2007-03-20 9:43 ` Pavel Machek
2007-03-20 9:46 ` Johannes Berg
2007-03-20 10:17 ` [PATCH] add firmware disk state and clean up Johannes Berg
2007-03-20 10:25 ` Pavel Machek
2007-03-20 10:45 ` Johannes Berg
2007-03-20 11:02 ` [PATCH] remove firmware disk mode Johannes Berg
2007-03-20 13:15 ` Pavel Machek
2007-03-20 11:06 ` [PATCH] implement pm_ops.valid for everybody Johannes Berg
2007-03-20 13:16 ` Pavel Machek
2007-03-20 23:44 ` David Brownell
2007-03-20 22:49 ` Pavel Machek
2007-03-21 21:01 ` Guennadi Liakhovetski
2007-03-21 22:07 ` David Brownell
2007-03-21 22:36 ` Guennadi Liakhovetski
2007-03-21 22:57 ` Pavel Machek
2007-03-21 23:25 ` David Brownell [this message]
2007-03-21 23:31 ` Pavel Machek
2007-03-22 10:03 ` Johannes Berg
2007-03-22 17:10 ` David Brownell
2007-03-22 17:18 ` Johannes Berg
2007-03-22 18:13 ` David Brownell
2007-03-22 18:18 ` Johannes Berg
2007-03-21 23:32 ` Rafael J. Wysocki
2007-03-20 22:59 ` [PATCH] add firmware disk state and clean up David Brownell
2007-03-20 22:09 ` Pavel Machek
2007-03-20 23:31 ` David Brownell
2007-03-20 11:48 ` [PATCH] rework pm_ops pm_disk_modes foo Johannes Berg
2007-03-22 13:44 [PATCH] implement pm_ops.valid for everybody Scott E. Preece
2007-03-22 18:29 ` David Brownell
2007-03-22 19:26 ` Tony Lindgren
2007-03-22 21:16 ` David Brownell
2007-03-23 13:15 ` tony
2007-03-23 18:25 ` David Brownell
2007-03-22 21:37 ` Rafael J. Wysocki
2007-03-22 21:27 ` Rafael J. Wysocki
2007-03-22 21:43 ` David Brownell
2007-03-22 21:56 ` Guennadi Liakhovetski
2007-03-22 22:42 ` David Brownell
2007-03-22 22:10 ` Rafael J. Wysocki
2007-03-22 22:56 ` David Brownell
2007-03-22 23:21 ` Rafael J. Wysocki
2007-03-22 23:55 ` David Brownell
2007-03-23 1:14 ` Matthew Locke
2007-03-23 13:17 ` tony
2007-03-23 13:35 ` Igor Stoppa
2007-03-23 14:52 ` tony
2007-03-23 15:17 ` Igor Stoppa
2007-03-23 18:51 ` Matthew Locke
2007-03-23 19:19 ` Igor Stoppa
2007-03-23 18:29 ` David Brownell
2007-03-23 19:21 ` Matthew Locke
2007-03-23 20:11 ` David Brownell
2007-03-23 6:46 ` Guennadi Liakhovetski
2007-03-23 16:15 ` David Brownell
2007-03-23 21:08 ` Guennadi Liakhovetski
2007-03-24 0:52 ` David Brownell
2007-03-23 13:43 ` Rafael J. Wysocki
2007-03-23 17:57 ` David Brownell
2007-03-23 20:39 ` Rafael J. Wysocki
2007-03-24 0:01 ` Pavel Machek
2007-03-24 0:54 ` David Brownell
2007-03-24 20:01 ` Rafael J. Wysocki
2007-03-24 0:41 ` Dmitry Krivoschekov
2007-03-24 20:49 ` David Brownell
2007-03-24 21:01 ` Johannes Berg
2007-03-25 1:02 ` David Brownell
2007-03-24 21:36 ` Rafael J. Wysocki
2007-03-24 22:19 ` David Brownell
2007-03-25 10:26 ` Dmitry Krivoschekov
2007-03-25 15:20 ` David Brownell
2007-03-25 16:23 ` Jim Gettys
2007-03-25 16:55 ` David Brownell
2007-03-23 18:18 ` Matthew Locke
2007-03-24 3:08 ` Paul Mackerras
2007-03-24 20:04 ` Rafael J. Wysocki
2007-03-22 23:29 ` Guennadi Liakhovetski
2007-03-22 23:44 ` David Brownell
2007-03-22 23:45 ` Guennadi Liakhovetski
2007-03-22 21:33 ` Rafael J. Wysocki
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=200703211625.23253.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=alexey.y.starikovskiy@intel.com \
--cc=ben@simtec.co.uk \
--cc=dirk.behme@de.bosch.com \
--cc=g.liakhovetski@gmx.de \
--cc=johannes@sipsolutions.net \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nico@cam.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