Re: Not able to use HIGH_RES_TIMERS on ARM

[John Stultz]

On 03/19/2012 06:26 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote:
> > Therefore our target configuration with 2.6 kernel was
> > GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y,
> It's absolutely absurd to have a platform converted to use clockevents
> and clocksources, and then select ARCH_USES_GETTIMEOFFSET.  That's saying
> "I provide the new infrastructure, but I want the dodgy old compatibility
> which doesn't work properly with a set of other features as well".
>
> > I conclude that GENERIC_CLOCKEVENTS is supported, hence I must set
> > ARCH_USES_GETTIMEOFFSET=n, in order to use NO_HZ, HIGH_RES_TIMERS,
> > IRQSOFF_TRACER, PREEMPT_TRACER
> Correct.  If you're using clockevents and clocksources, you should not
> select ARCH_USES_GETTIMEOFFSET.

Hey Ajeet,
    As Russell pointed out, it looks like you're confused as to the use 
of ARCH_USES_GETTIMEOFFSET. That option is only for legacy systems that 
don't provide continuous clocksources that can be used for timekeeping.

In the past, time was incremented by one tick every timer interrupt.  
Some systems could use the timer hardware (usually PIT style 
decrementer) to calculate inter-tick times. Its only for this style of 
hardware, that either wraps or resets each tick, that GETTIMEOFFSET is 
needed.  If you have a continuous counter that doesn't wrap for a 
reasonable number of ticks, you want to use the clocksource abstraction 
to represent that hardware. That has the benefits of allowing high res 
timers and nohz, since we don't need to keep a constant tick-beat to 
keep time (and also avoids lost-ticks and a host of problems that tick 
based timekeeping can run into).

So I suspect you probably want to verify your hardware supports a 
clocksource and disable ARCH_USES_GETTIMEOFFSET.

Sorry for any confusion!

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/