2011/6/25 Arve Hjønnevåg <arve@xxxxxxxxxxx>: > On Fri, Jun 24, 2011 at 12:53 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: > ... >> >> As I understand it, in the original Android implementation, the hardware >> that they were using didn't have fine-grained power management. So >> system-wide suspend made more sense in that context. But that shouldn't >> be confused with the modern rationale for wakelocks: >> >> https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html >> >> "On the hardware that shipped we enter the same power state from idle >> and suspend, so the only power savings we get from suspend that we >> don't get in idle is from not respecting the scheduler and timers." >> > > This is no longer the case. Both the Nexus-S and Xoom enter lower > power states from suspend than idle. Interesting, thanks for pointing that out. So this lower-power-state in system suspend, is that a hardware limitation, or just a reflection on effort spent on the CPUIdle portion of the current software implementation? I suspect it's the latter. I've recently been working towards implementing software support for deeper sleep modes on sh7372 in the mainline kernel. With my experimental patch the system suspend case may be able to sleep deeper that current CPUIdle, but that's only because I have not yet tied in enough dependency tracking to make proper decisions from CPUIdle context. Getting sleep modes working transparently with CPUIdle is currently a bit more difficult than simply using system suspend IMO, so I would not be surprised if some vendors simply skip implementing some deeper sleep modes in CPUIdle due to the added complexity. >From the hardware perspective nothing is stopping us to use CPUIdle with the lowest sleep states. This is true for all SH-Mobile SoCs including sh7372. Also, we don't rely on firmware for control of the PM states - if anyone is restricted by a firmware interface then obviously it's going to be difficult to do more fine grained power management. Cheers, / magnus -- 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
