On Tuesday 20 March 2007 4:06 am, Johannes Berg wrote: > Almost all users of pm_ops only support mem sleep, don't check in .valid > and don't reject any others in .prepare so users can be confused if they > check /sys/power/state, especially when new states are ever added. By the way ... as a note to implementors, it should be trivial to implement a basic "standby" state that suspends drivers, disables many clocks, and probably puts DRAM into self-refresh mode, but uses only the wait-for-interrupt CPU lowpower mode. A key difference between that and STR would then be that STR does extra magic, like switching the CPU to a slow clock and then turning off all the clocks that drive the chip "fast". Also, that because it disables so many clocks, the SOC probably can't support as many types of wakeup events in STR. I mention this because implementing such a "standby" mode means that all the platform drivers can start to make their suspend() and resume() code behave, and userspace tools can be put into place, before all that tricky/painful STR work gets done. Also, because driver wakeup events in such a "standby" mode tend to be a lot more powerful ... pretty much how a driver using runtime PM models would work (instead of user-visible "goto sleep"). That is, support for such a "standby" mode is the easiest way to seed all the PM work on a given platform. Even though it doesn't save as much power, it's a useful step towards deeper power saving modes. And thus endeth the lesson for today. I look forward to seeing a lot more platforms supporting at least minimal PM, now. ;) - Dave _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
