Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems
From: Todd Poynor (tpoynor_at_mvista.com)
Date: 03/02/05
- Previous message: Harry Edmon: "RAID1 sync crash with 2.6.11-rc5-mm1"
- In reply to: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Next in thread: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Reply: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 02 Mar 2005 13:58:49 -0800 To: Pavel Machek <pavel@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 - 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/
- Previous message: Harry Edmon: "RAID1 sync crash with 2.6.11-rc5-mm1"
- In reply to: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Next in thread: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Reply: Pavel Machek: "Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
