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!
