On Wednesday, July 13, 2011, Paul Walmsley wrote: > (cc'ing Len) > > Hi Mark, > > On Mon, 11 Jul 2011, Mark Brown wrote: > > > The interesting bits are things like being able to kill lots of the SoC > > core supplies when the RAM is in retention mode - the CPU needs to go > > through its shutdown procedures. > > This is indeed possible on OMAP3+ chips with TWL4030+ PMICs. Probably > other PMICs also. TI calls it "off-mode." The N900 shipped with this > feature enabled. Not sure how many other similar products did. > > This can be enabled in mainline, but not all of the mainline drivers have > context save/restore code merged yet, so in mainline it only works with a > subset of drivers. > > > Actually, it just occurred to me that if we're waiting for a system > > timer and can hand that off to a suitable timer in the PMIC then we can > > do a suspend to RAM for the deep idle state from the hardware point of > > view. > > Yep. At LinuxCon Cambridge two years ago, we had a discussion about > whether it would be possible to enter ACPI S-states from CPUIdle (or some > idle governor) on Intel chips. If I remember correctly, the conclusion > was that ACPI always disables the screen/backlight, so it would only be > useful for situations where that was acceptable. The reason why you can't enter ACPI S-states from CPUidle is because you need to go out of the idle loop to execute some ACPI-specific stuff. Which is not even specific to Intel chips, but to ACPI in general. So entering ACPI S-states from idle is a no-no and I don't think it'll change in foreseeable future. > To the best of my (limited) knowledge, that's the only case I know of > where there's a hardware limitation that prevents dynamic idle from > reaching the same low power state as system suspend. If someone has hard > details of a similar example, it would be great to know about it. Google G1 had this problem IIRC, but I don't have any details. Thanks, Rafael -- 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
