public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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