On Mon, May 17, 2010 at 08:47:31PM +0300, Felipe Balbi wrote: > IMO the real fix would be on that particular poll(), changing the > timeout e.g. based on cpufreq notifications or even relying completely > on IRQs with poll(pdfs, ARRAY_SIZE(pfds), -1); Of course, this is only a > crude example trying to show that the real issue lies on the application > rather than on kernel.
We know that this problem is mostly uninteresting if your userland is well written. The sad truth is that it's impossible to trust that your userland is well written, and broadly impossible to communicate to users that the reason that their battery life is miserable is because of the applications and not because of the platform. If you don't believe that that's a worthwhile use case to deal with then suspend blockers buy you pretty much nothing. But if you do, then nobody's yet demonstrated another workable way for this to be handled. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
