[PATCH 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX

Bedia, Vaibhav vaibhav.bedia at ti.com
Thu Nov 8 08:15:10 EST 2012


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



More information about the linux-arm-kernel mailing list