On Fri, 14 May 2010, Arve Hjønnevåg wrote: > > I'd like to explore this avenue a little farther. In particular, what > > is the issue involving loss of wakeup events? Can you describe this in > > more detail? > > > > On the desktop systems I have used I only wake the up the system by > pressing a button/key or with an rtc alarm. Losing a button or key > wakeup event is not usually a problem on a desktop since the user will > press it again. Losing an alarm however could be a problem and this > can be avoided by using opportunistic suspend and suspend blockers. How can runtime PM combined with CPUidle cause an alarm to be lost? > > Why would you want to use system suspend if runtime PM can do > > everything you need? > > > Because it stops threads that wakeup every second to check if they > have work to do (this includes standard kernel threads), and it > prevents bad apps that never go idle from completely destroying our > battery life. Ah, the ill-behaved apps problem. I think everybody agrees that they are hard to deal with. The kernel-threads problem might better be addressed by fixing those threads than by adding a new API. > > Sure, I can see that an ACPI-based system needs something more. But > > that's not the real issue here. > > > > The system we started with entered a much lower power state from > suspend than idle so we needed wakelocks to get more than 24 hours > battery life. We kept wakelocks when we moved to the msm platform > since it reduces our power consumption. Is it generally true among embedded systems nowadays that idle is capable of reaching essentially the same power states as suspend? Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
