On Fri, Apr 06, 2012 at 03:03:01, Hilman, Kevin wrote:
> "Hiremath, Vaibhav" <hvaibhav@xxxxxx> 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
>
--
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
