From: Todd Poynor <tpoynor@mvista.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, linux-pm@osdl.org
Subject: Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems
Date: Wed, 02 Mar 2005 13:58:49 -0800 [thread overview]
Message-ID: <42263719.7030004@mvista.com> (raw)
In-Reply-To: <20050302085619.GA1364@elf.ucw.cz>
Pavel Machek wrote:
> Hi!
>
>
>>Advertise custom sets of system power states for non-ACPI systems.
>>Currently, /sys/power/state shows and accepts a static set of choices
>>that are not necessarily meaningful on all platforms (for example,
>>suspend-to-disk is an option even on diskless embedded systems, and the
>>meaning of standby vs. suspend-to-mem is not well-defined on
>>non-ACPI-systems). This patch allows the platform to register power
>>states with meaningful names that correspond to the platform's
>>conventions (for example, "big sleep" and "deep sleep" on TI OMAP), and
>>only those states that make sense for the platform.
>
>
> Maybe this is a bit overdone?
>
> Of course you can have suspend-to-disk on most embedded systems; CF
> flash card looks just like disk, and you should be able to suspend to
> it.
It's possible (on those with CF/PCMCIA etc.), although due to various
problems with things like flash size, write speed, and wear leveling
it's not very common to do so (I've seen two vendors abandon plans for
this, but no doubt somebody does do it) -- that's why I'd like to have
the particular platform register the capability if it happens to have
it, but no, not a big deal.
> If OMAP has "big sleep" and "deep sleep", why not simply map them to
> "standby" and "suspend-to-ram"?
In fact that's more or less what happens (or will happen once drivers
like USB stop looking for PM_SUSPEND_MEM, etc.). There are other
platforms with more than 2 sleep states (say, XScale PXA27x), so this
will start to get a bit problematic. And it seens so easy to truly
handle the platform's states instead of pretending ACPI S1/S3/S4 are the
only methods to suspend any system.
If it's preferable, how about replacing the /sys/power/state "standby"
and "mem" values to "sleep", and have a /sys/power/sleep attribute that
tells the methods of sleep available for the platform, much like
suspend-to-disk methods are handled today? So the sleep attribute would
handle "standby" and "mem" for ACPI systems, and other values for
non-ACPI systems. Thanks,
--
Todd
next prev parent reply other threads:[~2005-03-02 22:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-02 2:03 [PATCH] Custom power states for non-ACPI systems Todd Poynor
2005-03-02 2:41 ` Todd Poynor
2005-03-02 2:57 ` [linux-pm] " Benjamin Herrenschmidt
2005-03-02 8:56 ` Pavel Machek
2005-03-02 21:58 ` Todd Poynor [this message]
2005-03-02 22:11 ` Pavel Machek
2005-03-03 0:26 ` Todd Poynor
2005-03-03 14:55 ` Pavel Machek
2005-03-04 2:01 ` David Brownell
2005-03-04 8:31 ` Pavel Machek
2005-03-04 2:10 ` Todd Poynor
2005-03-04 2:17 ` David Brownell
2005-03-04 4:49 ` Nigel Cunningham
2005-03-04 6:31 ` David Brownell
2005-03-04 20:50 ` Todd Poynor
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=42263719.7030004@mvista.com \
--to=tpoynor@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@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