Hi! > > 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"). Actually, I second that. "standby" that spins down disks to protect them for transport is very useful feature, even if it does not save much power. (Okay, that's notebooks and high-end-zauruses with spinning disks, but...) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
