* Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> [110711 04:21]: > On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote: > > * Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> [110711 03:59]: > > > > Right, but it can be interesting to tell the PMIC that we went into this > > > mode. Possibly cpuidle will end up doing this as a result of signals > > > generated as the CPU core goes down, but at that point it's just s2ram > > > by another name. > > > All PMIC devices should be shut down when not in use, so I don't know > > what else you would configure in the PMIC. Maybe you have something else > > there to configure? Just curious what kind of mess you have to deal with > > compared to the mess I need to deal with :) > > 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. I see. I've seen cases these are pre-programmed to the PMIC and then automatically triggered based on some event like WFI. > > Also, hitting deeper sleep states from idle is not same as suspend to ram. > > With suspend to ram the system timer is killed while timers behave in a > > normal way when hitting deeper sleep states from idle. > > 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. Cool, it would be nice to have a Linux generic way for programming a separate hardware wake-up timer. Not RTC, but some more accurate timer that might be too slow to access for general purpose usage. Regards, Tony -- 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
