[PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer

[Hiremath, Vaibhav]

On Fri, Apr 06, 2012 at 03:03:01, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav at ti.com> writes:
> 
> > On Thu, Apr 05, 2012 at 15:22:21, Russell King - ARM Linux wrote:
> >> On Thu, Apr 05, 2012 at 09:36:00AM +0000, Hiremath, Vaibhav wrote:
> >> > There seems to be limitation for ARM architecture, it is restricted by
> >> > sched_clock implementation present in "arch/arm/kernel/sched_clock.c".
> >> > Natively, clocksource framework does support change in rate/frequency for
> >> > registered timer, using,
> >> 
> >> Any kind of switching of timing sources introduces loss of time issues
> >> by the mere fact that you can't instantly know the counter values of
> >> both timing sources at precisely the same instant - because CPUs can
> >> only do one thing at a time.  So any kind of repeated dynamic switching
> >> _will_ result in a gradual loss of time - which will be indeterminant
> >> as it depends on the frequency of the switching and the relative delta
> >> between the two.
> >> 
> >> To put it another way - it is not possible to maintain high precision
> >> and accuracy while dynamically switching your timing sources.
> >> 
> >> I'm not about to lift the restriction that there's only one source for
> >> sched_clock() just for OMAP.  That'd require a lot of additional code -
> >> it's not just about adjusting the multiplier and shift, you also have to
> >> correct the returned ns value as well, which means synchronizing against
> >> two counters.  (And as I've pointed out above, that's impossible to do
> >> accurately.)
> >> 
> >
> > Thanks a ton Russell for confirming on this,
> >
> > I understand, we also have to adjust ns value and such confirmation is what exactly I was looking for.
> >
> > So this means, we have to use compile time option, as existing
> > implementation in "arch/arm/mach-omap2/timer.c".
> 
> Not exactly.  A compile time option isn't (yet) the only option.
> 
> Russell points out the various problems with dynamic switching of
> clocksources, which is true.  However, we're not trying to dynamically
> switch clocksources.
> 
> What we need is only one-time selection at boot based on presence (or
> not) of various timers.  IOW, we still only ever need to call
> setup_sched_clock() once based on which HW timers are available.
> 
> Why not just delay the setup_sched_clock() until the clocksource is
> decided?
> 

Kevin,

I liked Santosh's idea in using command line argument "clocksource=" and 
make decision based on this. I have implemented it and tried it on both
OMAP3EVM and beaglebone and it works great.

I have introduced something like this in mach-omap2/timer.c,

static int __init omap2_override_clocksource(char* str)
{
	if (!str)
		return 0;
	/*
	 * For OMAP architecture, we only have two options
	 *    - sync_32k (default)
	 *    - gp timer
	 */
	if (!strcmp(str, "gp timer"))
		use_gptimer_clksrc = true;

	return 0;
}
early_param("clocksource", omap2_override_clocksource);


It solves all issues what we have been trying address.

Thanks,

Vaibhav

> Kevin
>