Hi Santosh, On Tue, Nov 06, 2012 at 03:29:22, Shilimkar, Santosh wrote: [...] > > > > IMO, assuming that idle will not be useful from the begining is leading > > down the path to poor design choices that will be much more difficult to > > fixup down the road in order to add idle support later. We need to > > design both idle and suspend at the same time. > > > I agree with Kevin. Not supporting CPUIDLE deep states can hit the > active power numbers dearly. I just don't know why the SOCs don't share > the standard and must have design choices. But thats another discussion. > Yes, active power numbers are not comparable to OMAP :( > How about leaving the timer choices as is. PER timer for clock source > and wakeuptimer for clock event. Anyway in suspend the clock-source > can be suspended and that is evident from recent discussion. The only > downside is you won't count time in suspend which is any way the case. > > Vaibhav, > Do you guys see any implementation bottleneck for above ? > Looking at the timekeeping code I see one more potential reason for making this change. OMAP registers the 32k sync timer as the persistent clock and since there's no 32k sync timer in AM33xx it doesn't register a persistent clock right now. Based on what I understood, we need to have to register one and DMTimer1 is the only clock that can serve as the persistent clock in suspend state. When we do so we might as well use it as the clocksource. A related question that I had was, is there a mechanism to handle the 32k counter (DMTimer or sync timer) wraparound condition in suspend? Regards, Vaibhav -- 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
