Not able to use HIGH_RES_TIMERS on ARM

Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

Hi John, refering to you patch:

ARM: remove 'select GENERIC_TIME'
GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is
redundant.  Remove them.

The following config's are not selectable:
config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config
PREEMPT_TRACER

As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset()
infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y

diff -Naurp -X linux-3.0.20/Documentation/dontdiff
linux-3.0.20/kernel/time/Kconfig
linux-3.0.20-dirty/kernel/time/Kconfig
--- linux-3.0.20/kernel/time/Kconfig    2012-02-06 23:01:45.000000000 +0530
+++ linux-3.0.20-dirty/kernel/time/Kconfig      2012-03-19
18:22:32.000000000 +0530
@@ -6,7 +6,7 @@ config TICK_ONESHOT

 config NO_HZ
        bool "Tickless System (Dynamic Ticks)"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
        select TICK_ONESHOT
        help
          This option enables a tickless system: timer interrupts will
@@ -15,7 +15,7 @@ config NO_HZ

 config HIGH_RES_TIMERS
        bool "High Resolution Timer Support"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
        select TICK_ONESHOT
        help
          This option enables high resolution timer support. If your
diff -Naurp -X linux-3.0.20/Documentation/dontdiff
linux-3.0.20/kernel/trace/Kconfig
linux-3.0.20-dirty/kernel/trace/Kconfig
--- linux-3.0.20/kernel/trace/Kconfig   2012-02-06 23:01:45.000000000 +0530
+++ linux-3.0.20-dirty/kernel/trace/Kconfig     2012-03-19
18:21:41.000000000 +0530
@@ -173,7 +173,6 @@ config IRQSOFF_TRACER
        bool "Interrupts-off Latency Tracer"
        default n
        depends on TRACE_IRQFLAGS_SUPPORT
-       depends on !ARCH_USES_GETTIMEOFFSET
        select TRACE_IRQFLAGS
        select GENERIC_TRACER
        select TRACER_MAX_TRACE
@@ -195,7 +194,6 @@ config IRQSOFF_TRACER
 config PREEMPT_TRACER
        bool "Preemption-off Latency Tracer"
        default n
-       depends on !ARCH_USES_GETTIMEOFFSET
        depends on PREEMPT
        select GENERIC_TRACER
        select TRACER_MAX_TRACE

Re: Not able to use HIGH_RES_TIMERS on ARM

[Russell King - ARM Linux]

On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote:
> Hi John, refering to you patch:
> 
> ARM: remove 'select GENERIC_TIME'
> GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is
> redundant.  Remove them.
> 
> The following config's are not selectable:
> config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config
> PREEMPT_TRACER
> 
> As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset()
> infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y

No.  It is possible to select these options, but only if your platform
uses the clockevent and clocksource infrastructure.  If you're using that,
then you must _not_ select ARCH_USES_GETTIMEOFFSET.

ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted
platforms, which are _not_ possible to use the above features.

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

On Mon, Mar 19, 2012 at 6:34 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote:
>> Hi John, refering to you patch:
>>
>> ARM: remove 'select GENERIC_TIME'
>> GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is
>> redundant.  Remove them.
>>
>> The following config's are not selectable:
>> config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config
>> PREEMPT_TRACER
>>
>> As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset()
>> infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y
>
> No.  It is possible to select these options, but only if your platform
> uses the clockevent and clocksource infrastructure.  If you're using that,
> then you must _not_ select ARCH_USES_GETTIMEOFFSET.
>
> ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted
> platforms, which are _not_ possible to use the above features.

Just before the patch "time: Kill off CONFIG_GENERIC_TIME" Generic
time was selectable option,
Therefore our target configuration with 2.6 kernel was
GENERIC_CLOCKEVENTS=y, ARCH_USES_GETTIMEOFFSET=y,
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

Re: Not able to use HIGH_RES_TIMERS on ARM

[Russell King - ARM Linux]

On Mon, Mar 19, 2012 at 06:49:34PM +0530, Ajeet Yadav wrote:
> On Mon, Mar 19, 2012 at 6:34 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Mar 19, 2012 at 06:31:44PM +0530, Ajeet Yadav wrote:
> >> Hi John, refering to you patch:
> >>
> >> ARM: remove 'select GENERIC_TIME'
> >> GENERIC_TIME is now enabled by default, so 'select GENERIC_TIME' is
> >> redundant.  Remove them.
> >>
> >> The following config's are not selectable:
> >> config NO_HZ, config HIGH_RES_TIMERS, config IRQSOFF_TRACER, config
> >> PREEMPT_TRACER
> >>
> >> As far as I know, ARM now uses GENERIC_TIME via the arch_getoffset()
> >> infrastructure, i.e ARCH_USES_GETTIMEOFFSET=y
> >
> > No.  It is possible to select these options, but only if your platform
> > uses the clockevent and clocksource infrastructure.  If you're using that,
> > then you must _not_ select ARCH_USES_GETTIMEOFFSET.
> >
> > ARCH_USES_GETTIMEOFFSET is for compatibility with old unconverted
> > platforms, which are _not_ possible to use the above features.
> 
> Just before the patch "time: Kill off CONFIG_GENERIC_TIME" Generic
> time was selectable option,

CONFIG_GENERIC_TIME was always set to 'y' on ARM (and everything else)
before that commit.  As the option is always set, there's no point it
existing.  So it was removed, and all the code paths associated with
it became unconditional.

Yes, there are places where GENERIC_TIME was subsituted with
!ARCH_USES_GETTIMEOFFSET.  (John will know the details.)

> 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.

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

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

Hi John,
Thank for clearing the confusion.

On Wed, Mar 21, 2012 at 10:28 AM, John Stultz <john.stultz@linaro.org> wrote:
> 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
>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

Hi John,
On our target  ARCH_USES_GETTIMEOFFSET=y, can you please help me how
can I useIRQSOFF_TRACER, PREEMPT_TRACER ?


On Wed, Mar 21, 2012 at 3:46 PM, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
> Hi John,
> Thank for clearing the confusion.
>
> On Wed, Mar 21, 2012 at 10:28 AM, John Stultz <john.stultz@linaro.org> wrote:
>> 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
>>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Russell King - ARM Linux]

On Thu, Mar 22, 2012 at 02:46:31PM +0530, Ajeet Yadav wrote:
> Hi John,
> On our target  ARCH_USES_GETTIMEOFFSET=y, can you please help me how
> can I useIRQSOFF_TRACER, PREEMPT_TRACER ?

If you have ARCH_USES_GETTIMEOFFSET=y, the simple answer is: you can't.

Your solution is to update your platform to use clock sources and clock
events and disable the obsolete ARCH_USES_GETTIMEOFFSET option.

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

I understand your point,
Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we
were able to use the TRACER in past until the patch "kill
GENERIC_TIMER" published, anyone will ask me remove this patch and use
TRACER, becaue it was working before. :)

If I set  ARCH_USES_GETTIMEOFFSET=n to use this feature, my target
fail to boot. (reason I well understand from our past discussions)

but if do below, everything work find target as well as tracer.

--- linux-3.0.20/kernel/time/Kconfig    2012-02-06 23:01:45.000000000 +0530
+++ linux-3.0.20-dirty/kernel/time/Kconfig      2012-03-19
18:22:32.000000000 +0530
@@ -6,7 +6,7 @@ config TICK_ONESHOT

 config NO_HZ
       bool "Tickless System (Dynamic Ticks)"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
       select TICK_ONESHOT
       help
         This option enables a tickless system: timer interrupts will
@@ -15,7 +15,7 @@ config NO_HZ

 config HIGH_RES_TIMERS
       bool "High Resolution Timer Support"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
       select TICK_ONESHOT
       help
         This option enables high resolution timer support. If your

On Thu, Mar 22, 2012 at 3:32 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Mar 22, 2012 at 02:46:31PM +0530, Ajeet Yadav wrote:
>> Hi John,
>> On our target  ARCH_USES_GETTIMEOFFSET=y, can you please help me how
>> can I useIRQSOFF_TRACER, PREEMPT_TRACER ?
>
> If you have ARCH_USES_GETTIMEOFFSET=y, the simple answer is: you can't.
>
> Your solution is to update your platform to use clock sources and clock
> events and disable the obsolete ARCH_USES_GETTIMEOFFSET option.

Re: Not able to use HIGH_RES_TIMERS on ARM

[John Stultz]

On 03/22/2012 03:25 AM, Ajeet Yadav wrote:
> I understand your point,
> Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we
> were able to use the TRACER in past until the patch "kill
> GENERIC_TIMER" published, anyone will ask me remove this patch and use
> TRACER, becaue it was working before. :)

Ajeet,
     Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And 
what specific 2.6.X kernel were you using?

Steven, I'm seeing:
config PREEMPT_TRACER
         bool "Preemption-off Latency Tracer"
         default n
         depends on !ARCH_USES_GETTIMEOFFSET

Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here?

thanks
-john

Re: Not able to use HIGH_RES_TIMERS on ARM

[John Stultz]

On 03/22/2012 03:25 AM, Ajeet Yadav wrote:
> If I set  ARCH_USES_GETTIMEOFFSET=n to use this feature, my target
> fail to boot. (reason I well understand from our past discussions)
And this point I'm not sure I'm following. Why exactly does disabling 
ARCH_USES_GETTIMEOFFSET cause boot failures? Could you expand on the 
details here?

You should just end up using the jiffies clocksource, which would give 
you low-res HZ granular timestamps, but shouldn't get in the way of booting.

thanks
-john

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

On Fri, Mar 23, 2012 at 8:53 AM, John Stultz <john.stultz@linaro.org> wrote:
> On 03/22/2012 03:25 AM, Ajeet Yadav wrote:
>>
>> I understand your point,
>> Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we
>> were able to use the TRACER in past until the patch "kill
>> GENERIC_TIMER" published, anyone will ask me remove this patch and use
>> TRACER, becaue it was working before. :)
>
>
> Ajeet,
>    Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And what
> specific 2.6.X kernel were you using?
IRQSOFF_TRACER and PREEMPT_TRACER, our old kernel was 2.6.35.
>
> Steven, I'm seeing:
>
> config PREEMPT_TRACER
>        bool "Preemption-off Latency Tracer"
>        default n
>        depends on !ARCH_USES_GETTIMEOFFSET
>
> Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here?
>
> thanks
> -john
>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

CCing to stable@vger.kernel.org
On Fri, Mar 23, 2012 at 8:58 AM, John Stultz <john.stultz@linaro.org> wrote:
> On 03/22/2012 03:25 AM, Ajeet Yadav wrote:
>>
>> If I set  ARCH_USES_GETTIMEOFFSET=n to use this feature, my target
>> fail to boot. (reason I well understand from our past discussions)
>
> And this point I'm not sure I'm following. Why exactly does disabling
> ARCH_USES_GETTIMEOFFSET cause boot failures? Could you expand on the details
> here?
We did some dissection to narrow down the patch, our latest kernel is
stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7:
Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this
patch causes kernel hang during boot (IRQSOFF_TRACER=y and
PREEMPT_TRACER=y) with 100% probability , if we remove this patch or
disable the given CONFIG's then boot is success.
>
> You should just end up using the jiffies clocksource, which would give you
> low-res HZ granular timestamps, but shouldn't get in the way of booting.
>
> thanks
> -john
>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Rabin Vincent]

On Fri, Mar 23, 2012 at 11:22, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
> We did some dissection to narrow down the patch, our latest kernel is
> stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7:
> Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this
> patch causes kernel hang during boot (IRQSOFF_TRACER=y and
> PREEMPT_TRACER=y) with 100% probability , if we remove this patch or
> disable the given CONFIG's then boot is success.

8e43a905dd574f54c5715d9783 ("ARM: 7325/1: fix v7 boot with lockdep
enabled") fixes 7321/1's boot problems.

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

On Fri, Mar 23, 2012 at 11:47 AM, Rabin Vincent <rabin@rab.in> wrote:
> On Fri, Mar 23, 2012 at 11:22, Ajeet Yadav <ajeet.yadav.77@gmail.com> wrote:
>> We did some dissection to narrow down the patch, our latest kernel is
>> stable 3.0.X , however we backported patch " ARM: 7321/1: cache-v7:
>> Disable preemption when reading CCSIDR" from 3.0.25 stable tree, this
>> patch causes kernel hang during boot (IRQSOFF_TRACER=y and
>> PREEMPT_TRACER=y) with 100% probability , if we remove this patch or
>> disable the given CONFIG's then boot is success.
>
> 8e43a905dd574f54c5715d9783 ("ARM: 7325/1: fix v7 boot with lockdep
> enabled") fixes 7321/1's boot problems.
Hi Rabin,
Thanks for fixing the boot problem, we have tested it, fixed.

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

On Fri, Mar 23, 2012 at 8:53 AM, John Stultz <john.stultz@linaro.org> wrote:
> On 03/22/2012 03:25 AM, Ajeet Yadav wrote:
>>
>> I understand your point,
>> Our target (2.6) always had ARCH_USES_GETTIMEOFFSET=y , but still we
>> were able to use the TRACER in past until the patch "kill
>> GENERIC_TIMER" published, anyone will ask me remove this patch and use
>> TRACER, becaue it was working before. :)
>
>
> Ajeet,
>    Sorry, by TRACER, do you mean PREEMPT_TRACER or something else? And what
> specific 2.6.X kernel were you using?
>
> Steven, I'm seeing:
>
> config PREEMPT_TRACER
>        bool "Preemption-off Latency Tracer"
>        default n
>        depends on !ARCH_USES_GETTIMEOFFSET
>
> Do you have any context as to why is !ARCH_USES_GETTIMEOFFSET flagged here?
Since boot problem is now fixed, I removed  "depends on
!ARCH_USES_GETTIMEOFFSET" from config NO_HZ, config HIGH_RES_TIMERS,
config IRQSOFF_TRACER, config
PREEMPT_TRACER, to continue my work.

Ref: time: Kill off CONFIG_GENERIC_TIME
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=592913ecb87a9e06f98ddb55b298f1a66bf94c6b

diff -Naurp -X linux-3.0.20/Documentation/dontdiff
linux-3.0.20/kernel/time/Kconfig
linux-3.0.20-dirty/kernel/time/Kconfig
--- linux-3.0.20/kernel/time/Kconfig    2012-02-06 23:01:45.000000000 +0530
+++ linux-3.0.20-dirty/kernel/time/Kconfig      2012-03-19
18:22:32.000000000 +0530
@@ -6,7 +6,7 @@ config TICK_ONESHOT

 config NO_HZ
       bool "Tickless System (Dynamic Ticks)"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
       select TICK_ONESHOT
       help
         This option enables a tickless system: timer interrupts will
@@ -15,7 +15,7 @@ config NO_HZ

 config HIGH_RES_TIMERS
       bool "High Resolution Timer Support"
-       depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
+       depends on GENERIC_CLOCKEVENTS
       select TICK_ONESHOT
       help
         This option enables high resolution timer support. If your
diff -Naurp -X linux-3.0.20/Documentation/dontdiff
linux-3.0.20/kernel/trace/Kconfig
linux-3.0.20-dirty/kernel/trace/Kconfig
--- linux-3.0.20/kernel/trace/Kconfig   2012-02-06 23:01:45.000000000 +0530
+++ linux-3.0.20-dirty/kernel/trace/Kconfig     2012-03-19
18:21:41.000000000 +0530
@@ -173,7 +173,6 @@ config IRQSOFF_TRACER
       bool "Interrupts-off Latency Tracer"
       default n
       depends on TRACE_IRQFLAGS_SUPPORT
-       depends on !ARCH_USES_GETTIMEOFFSET
       select TRACE_IRQFLAGS
       select GENERIC_TRACER
       select TRACER_MAX_TRACE
@@ -195,7 +194,6 @@ config IRQSOFF_TRACER
 config PREEMPT_TRACER
       bool "Preemption-off Latency Tracer"
       default n
-       depends on !ARCH_USES_GETTIMEOFFSET
       depends on PREEMPT
       select GENERIC_TRACER
       select TRACER_MAX_TRACE

>
> thanks
> -john
>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Steven Rostedt]

On Fri, 2012-03-23 at 14:40 +0530, Ajeet Yadav wrote:

> linux-3.0.20/kernel/trace/Kconfig
> linux-3.0.20-dirty/kernel/trace/Kconfig
> --- linux-3.0.20/kernel/trace/Kconfig   2012-02-06 23:01:45.000000000 +0530
> +++ linux-3.0.20-dirty/kernel/trace/Kconfig     2012-03-19
> 18:21:41.000000000 +0530
> @@ -173,7 +173,6 @@ config IRQSOFF_TRACER
>        bool "Interrupts-off Latency Tracer"
>        default n
>        depends on TRACE_IRQFLAGS_SUPPORT
> -       depends on !ARCH_USES_GETTIMEOFFSET
>        select TRACE_IRQFLAGS
>        select GENERIC_TRACER
>        select TRACER_MAX_TRACE
> @@ -195,7 +194,6 @@ config IRQSOFF_TRACER
>  config PREEMPT_TRACER
>        bool "Preemption-off Latency Tracer"
>        default n
> -       depends on !ARCH_USES_GETTIMEOFFSET
>        depends on PREEMPT
>        select GENERIC_TRACER
>        select TRACER_MAX_TRACE

A little history here.

When I converted the irqsoff/preemptoff latency tracers from the
original -rt patch (written by Ingo), these options originally had
"depends on GENERIC_TIME". I just checked, and this goes at least back
to 2.6.22.1-rt9 (long before ftrace).

When I ported these to ftrace, I kept the dependencies. They probably
are not needed and are only there for historical reasons.

If this patch works fine for you, and that you are my only test case for
this patch. I'd just say:

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: Not able to use HIGH_RES_TIMERS on ARM

[Greg KH]

On Fri, Mar 23, 2012 at 11:22:46AM +0530, Ajeet Yadav wrote:
> CCing to stable@vger.kernel.org

Why?  What am I supposed to do here?

confused,

greg k-h

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

I send earlier reply using my andriod gmail application, and it was
rejected by stable/ linux-kernel (not in plain text), so sending again
using PC.

On Fri, Mar 23, 2012 at 9:44 PM, Greg KH <greg@kroah.com> wrote:
> On Fri, Mar 23, 2012 at 11:22:46AM +0530, Ajeet Yadav wrote:
>> CCing to stable@vger.kernel.org
>
> Why?  What am I supposed to do here?
>
> confused,
>
> greg k-h
I initially thought that problem is in 3.0.x stable, but I was wrong.
Solution patch suggested by Rabin is already there in stable.
Summary:
" ARM: 7321/1: cache-v7: > Disable preemption when reading CCSIDR"
introduce hang on boot, that is resolved by commit

"ARM: 7325/1: fix v7 boot with lockdep enabled"
 fortunately both are in 3.0.x so no problem,

but i do not know about other stable versions.

Re: Not able to use HIGH_RES_TIMERS on ARM

[Ajeet Yadav]

On Fri, Mar 23, 2012 at 7:58 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 2012-03-23 at 14:40 +0530, Ajeet Yadav wrote:
>
>> linux-3.0.20/kernel/trace/Kconfig
>> linux-3.0.20-dirty/kernel/trace/Kconfig
>> --- linux-3.0.20/kernel/trace/Kconfig   2012-02-06 23:01:45.000000000 +0530
>> +++ linux-3.0.20-dirty/kernel/trace/Kconfig     2012-03-19
>> 18:21:41.000000000 +0530
>> @@ -173,7 +173,6 @@ config IRQSOFF_TRACER
>>        bool "Interrupts-off Latency Tracer"
>>        default n
>>        depends on TRACE_IRQFLAGS_SUPPORT
>> -       depends on !ARCH_USES_GETTIMEOFFSET
>>        select TRACE_IRQFLAGS
>>        select GENERIC_TRACER
>>        select TRACER_MAX_TRACE
>> @@ -195,7 +194,6 @@ config IRQSOFF_TRACER
>>  config PREEMPT_TRACER
>>        bool "Preemption-off Latency Tracer"
>>        default n
>> -       depends on !ARCH_USES_GETTIMEOFFSET
>>        depends on PREEMPT
>>        select GENERIC_TRACER
>>        select TRACER_MAX_TRACE
>
> A little history here.
>
> When I converted the irqsoff/preemptoff latency tracers from the
> original -rt patch (written by Ingo), these options originally had
> "depends on GENERIC_TIME". I just checked, and this goes at least back
> to 2.6.22.1-rt9 (long before ftrace).
>
> When I ported these to ftrace, I kept the dependencies. They probably
> are not needed and are only there for historical reasons.
>
> If this patch works fine for you, and that you are my only test case for
> this patch. I'd just say:
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> -- Steve
Hi Steve thanks for review, is their anything more I can do or shall I
consider this change as already submitted, thanks everyone for helping
me.
>
>

Re: Not able to use HIGH_RES_TIMERS on ARM

[Steven Rostedt]

On Sat, 2012-03-24 at 12:36 +0530, Ajeet Yadav wrote:

> Hi Steve thanks for review, is their anything more I can do or shall I
> consider this change as already submitted, thanks everyone for helping
> me.
> >
> >

I can pull this in. Do they need to go into 3.4? Or can you wait till
3.5?

-- Steve