[Top] [All Lists]

Re: [RFC] Separate time support for using cpu timer

To: Jun Sun <>
Subject: Re: [RFC] Separate time support for using cpu timer
From: "Maciej W. Rozycki" <>
Date: Tue, 20 Apr 2004 15:41:32 +0200 (CEST)
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
References: <>
On Mon, 19 Apr 2004, Jun Sun wrote:

> Solution
> --------
> All the boards that I am really concerned right now have cpu count/compare
> registers.  I believe this will even more so in the future.
> Therefore I like to propose a separate time support for systems that use
> cpu timer as their system timer.
> As you can see from the patch, the new code is much simpler.

 It makes it separate again -- more maintenance burden and a bigger
opportunity to have functional divergence, sigh...

 Additionally I don't think using the CP0 Count & Compare registers for
the system timer is the way to go.  It's rather a way to escape when
there's no other possibility.  A lot of systems have a reliable external
timer interrupt source and using it actually would free the CP0 registers
for other uses, like profiling or a programmable interval timer.

> The hidden agenda
> -----------------
> OK, I admit there is another motivation in all of this.  Linux is moving
> to have higher resolution timer.  For example, see the introduction of high 
> resolution 
> posix timer (  Having a 
> MIPS common
> time routine based on cpu timer makes it much easier to support
> such a feature for MIPS boards.  We don't need to mess with individual board 
> timer
> anymore.
> In addition I think in 2.7 time frame Linux needs to replace its ancient jiffy
> time system with a natively higher resolution time system.  A MIPS cpu timer 
> based 
> routine would evolve much better into the future.

 Well, I don't think the two issues are coupled together, although, there
may be certain dependencies.  E.g. an external time source may actually
have a good resolution.

 Anyway, the details may be worth discussing when 2.7 spins off,
preferably on the LKML, as this is about generic support.


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>