On Tue, May 04, 2010 at 11:06:39AM -0700, Kevin Hilman wrote: > With opportunistic suspend, all of this flexibility is gone, and the > device/subsystem is told to go into the lowest power, highest latency > state, period. Well, half the problem I have is that unfortunately it's not a case of doing that period. The prime example I'm familiar with is that for understandable reasons users become irate when you power down the audio CODEC while they're in the middle of a call so if opportunistic PM is in use then the audio subsystem needs some additional help interpreting a suspend request so that it can figure out how to handle it. Similar issues apply to PMICs, though less pressingly for various reasons. Just to be clear, I do understand and mostly agree with the idea that opportunistic suspend presents a reasonable workaround for our current inability to deliver good power savings with runtime PM methods on many important platforms but I do think that if we're going to make this standard Linux PM functionality then we need to be clearer about how everything is intended to hang together. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
