Message-ID: <42263719.7030004@mvista.com>
Date: Wed, 02 Mar 2005 13:58:49 -0800
From: Todd Poynor <tpoynor@mvista.com>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041103)
MIME-Version: 1.0
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
References: <20050302020306.GA5724@slurryseal.ddns.mvista.com> <20050302085619.GA1364@elf.ucw.cz>
In-Reply-To: <20050302085619.GA1364@elf.ucw.cz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2348
Lines: 53

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/