[PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
Hiremath, Vaibhav
hvaibhav at ti.com
Thu Apr 5 06:31:34 EDT 2012
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".
Thanks again, I will repost patches shortly with the code changes (mentioned
in my last email)
Thanks,
Vaibhav
More information about the linux-arm-kernel
mailing list