From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: David Brownell <david-b@pacbell.net>
Cc: alexey.y.starikovskiy@intel.com,
linux-arm@lists.arm.linux.org.uk, dirk.behme@de.bosch.com,
johannes@sipsolutions.net, pavel@ucw.cz,
linux-pm@lists.linux-foundation.org, nico@cam.org,
ben@simtec.co.uk, g.liakhovetski@gmx.de
Subject: Re: [PATCH] implement pm_ops.valid for everybody
Date: Thu, 22 Mar 2007 22:27:04 +0100 [thread overview]
Message-ID: <200703222227.06473.rjw@sisk.pl> (raw)
In-Reply-To: <200703221129.28722.david-b@pacbell.net>
On Thursday, 22 March 2007 19:29, David Brownell wrote:
> On Thursday 22 March 2007 6:44 am, Scott E. Preece wrote:
> > | From: "Rafael J. Wysocki" <rjw@sisk.pl>
> > |
> > | I think we can define "standby" a bit more precisely. Something like:
> > | - processes are frozen,
> > | - devices are suspended,
>
> True of all sleep states, although one wants "suspended" to
> allow different levels of device functionality. (Maybe it
> can wake up, maybe its firmware is monitoring the WLAN, etc.)
>
>
> > | - nonboot CPUs are down (and in low powered states, if possible),
> > | - the boot CPU may or may not be in a low power state, depending on the platform,
>
> Both seem platform-specific. One might want the DSP to be fully
> active while the control CPU is in a lowpower state, etc.
>
>
> > | - "system" devices may or may not be suspended, depending on the platform,
>
> ... so this "restriction" is meaningless ...
>
>
> > | - RAM is powered
>
> I think that's assumed by all states except suspend-to-disk. Modulo
> the potential for powering off the unused banks, of course.
>
>
> > | - wake up need not be BIOS-driven (main difference from "mem")
> > ---
> >
> > I would be tempted to say that that last bullet is the distinguishing
> > characteristic - that you come back from standby by just continuing
> > where you left off, but you come back from StR by something akin to
> > booting.
>
> I was going to say that even thinking about a "BIOS" is an x86-ism,
> so this would be an unusably non-generic rule. :)
>
> SOC systems often need to drive their deepest sleep states from code
> living in on-chip SRAM (maybe 16 KB). Sometimes that's also done in
> conjunction with code from an on-chip mask ROM, especially if the CPU
> itself gets powered off. That's not BIOS...
>
>
> ... but I guess I don't see why one would want to try to nail down
> a definition of either "standby" or "STR".
So that the meaning of "standby" and "STR" is known, more or less.
If you say "I'd like platforms to implement standby", you should say what
you mean by "standby", IMHO.
> The implementation will necessarily be highly platform-specific, to the
> extent that almost any rule will need to be broken somewhere. So, why
> bother trying to fit every system into the mold of APM/ACPI terminology?
Actually, I don't care what the definition will be. Still, I'd like to have
a definition.
Greetings,
Rafael
next prev parent reply other threads:[~2007-03-22 21:27 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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 10:17 ` [PATCH] add firmware disk state and clean up Johannes Berg
2007-03-20 10:25 ` 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
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
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=200703222227.06473.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=alexey.y.starikovskiy@intel.com \
--cc=ben@simtec.co.uk \
--cc=david-b@pacbell.net \
--cc=dirk.behme@de.bosch.com \
--cc=g.liakhovetski@gmx.de \
--cc=johannes@sipsolutions.net \
--cc=linux-arm@lists.arm.linux.org.uk \
--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