Hi!
> >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,
This is userland API. It should not change in random way during stable
series...
...but adding new /sys/power/state might be okay. We should not have
introduced "standby" in the first place [but I guess it is not worth
removing now]. If something has more than 2 states (does user really
want to enter different states in different usage?), I guess we can
add something like "deepmem" or whatever. Is there something with more
than 3 states?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
