[Top] [All Lists]

Re: Kernel interface for MIPS timers....

To: "Steven J. Hill" <>
Subject: Re: Kernel interface for MIPS timers....
From: Jun Sun <>
Date: Mon, 24 Nov 2003 10:31:01 -0800
In-reply-to: <>; from on Mon, Nov 24, 2003 at 08:00:15AM -0500
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.2.5i
On Mon, Nov 24, 2003 at 08:00:15AM -0500, Steven J. Hill wrote:
> Hello.
> This could be an embarassing question, but I seem to be good at
> asking those anyway. A lot more MIPS processors lately seem to
> come with multiple timers. In addition to the main HPT timer on
> R4K variants and above, usually there are 2 or 3 additional 16
> or 32-bit timers with prescalars and other features. Some drivers
> may decide to use one of these timers exclusively and I am sure
> there are many other uses as well. There does not seem to be any
> type of API or reservation system to cleanly utilize the timers
> present in the system. Actually, on a lot of my boards the added
> timers do not get any usage, but perhaps that could change. Has
> anyone given thought to this, or does it just seem pointless?

I afraid it might be later. :)

Kernel needs one timer, i.e., the system or jiffy timer.  All
other time or timer services are provided based on it.

Individual drivers or application may use the other timers, but
that does not mean kernel needs to explicitly manage them.

Given that said, Monta Vista recently has implemented high resolution
posix timer, in which case we do abstract out two system timers,
one for jiffy, and other is for high resolution stuff.  (Individual
board, however, is free to multiplex the same hw timer for both 
purposes in its implementation)

Personally I don't think this approach is perfect.  The ultimate right 
solution is to have a single high resolution timer interface native to
the kernel, and we emulate jiffy timer on top to provide continuing support
for existing (or legacy) jiffy timer services.

This is something which should be interesting for 2.7.


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