Hi Santosh, On Tue, Nov 06, 2012 at 20:05:40, Bedia, Vaibhav wrote: > 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? > Does interchanging the clksrc and clkevt look fine to you? 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
