On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > > The fundamental problem is one of idleness. What we want is the > system to be idle in order to hit the lowest power states. We can't > get there because the system is not truly idle. > > So, there are basically two solutions: > > 1) find and fix the problem spots so we can be idle more often > 2) add a new definition of idle so we can be idle more often > > Opporuntistic suspend takes the second approach where the new > definition of idle is "no suspend blockers held." > > Of course, I clearly prefer the former, but it's also becoming clear > that since I'm the only one still whining about it, I must be too much > of an idealist to keep hoping for it. I'd love to see the former work, but it is not something that I think is going to be fixed rapidly. It potentially involves many different subsystems, and still requires some need for managing arbitrary userspace agents which may have non-ideal behaviors (if we're going to solve the problem for general purpose devices that can run arbitrary user-installed software). Incremental improvements are great though (for example, that we can now be in lowest power idle for periods greater than 2 seconds due to the change in .32). Even when operating in opportunistic suspend, it is still advantageous for idle to be as idle as possible and we should keep working toward that goal. If we get to the point where the power difference between suspend-in-idle and opportunistic suspend is zero, then we no longer need the latter. I don't think anybody on the Google/Android side is arguing that we *shouldn't* pursue dynamic pm and overall making idle more idle more of the time. We're just saying that here and now we are not at the ideal and opportunistic suspend gains us real power savings and is useful. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
