Re: [PATCH][RFC] sort out CLOCK_TICK_RATE usage [1/3]

[Thorsten Kranzkowski <dl8bcu@dl8bcu.de>]

On Mon, Apr 12, 2004 at 09:39:43AM -0700, David Mosberger wrote:
> >>>>> On Mon, 12 Apr 2004 07:57:05 +0000, Thorsten Kranzkowski <dl8bcu@dl8bcu.de> said:
> 
>   Thorsten> Introducing PIC_TIC_RATE.
> 
> What's this meant for?  At least for IA-64, there is zero guarantee
> that there will be a timer ticking at this rate.  There are some
> machines where this is the case (the ones using Intel chipsets, I
> believe), but it isn't true for most machines with non-Intel chipsets
> (which are common).

This is the base frequency of the programmable interrupt timer/counter 
(originally a 8253 I think) that on some architectures serves as the 
system timer but on even more architectures drives the system speaker
with it's 3rd timer.

There are these lines in the pcspkr.c (and the other *spkr.c):

        if (value > 20 && value < 32767)
                count = PIC_TICK_RATE / value;

Thos evaluates the count the timer is programmed to generate a
given frequency (value).
In 2.6.5 this reads CLOCK_TICK_RATE which is definitely not correct
as the system clock is not necessarily driven by this chip (timer 0).
Older versions (kernel 2.4.x) of the speaker driver used a hardcoded
value but there seem to exist at least some strange i386 variants where 
this frequency is not the traditional one. 

So I thought an architectural define was appropriate. Maybe timex.h is
not the best place to put it in.


Bye,
Thorsten

-- 
| Thorsten Kranzkowski        Internet: dl8bcu@dl8bcu.de                      |
| Mobile: ++49 170 1876134       Snail: Kiebitzstr. 14, 49324 Melle, Germany  |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |