linux-mips
[Top] [All Lists]

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

To: Jun Sun <jsun@mvista.com>
Subject: Re: [RFC] Separate time support for using cpu timer
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 20 Apr 2004 15:41:32 +0200 (CEST)
Cc: linux-mips@linux-mips.org
In-reply-to: <20040419180720.H14976@mvista.com>
Organization: Technical University of Gdansk
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20040419180720.H14976@mvista.com>
Sender: linux-mips-bounce@linux-mips.org
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 (http://sourceforge.net/projects/high-res-timers/).  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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

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