[linux-pm] [PATCH] Custom power states for non-ACPI systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux