lkml.org 
[lkml]   [2012]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Not able to use HIGH_RES_TIMERS on ARM
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



\
 
 \ /
  Last update: 2012-03-21 06:03    [W:2.292 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site