[lkml]   [2003]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

I've taken Linus out of the CC list as he'll not want to see this until
it's all sorted out...

>>> ChangeSet@1.1215.104.25, 2003-06-09 14:41:31+02:00,
>>> input: Change input/misc/pcspkr.c to use CLOCK_TICK_RATE instead of
>>> a fixed value of 1193182. And change CLOCK_TICK_RATE and several
>>> usages of a fixed value 1193180 to a slightly more correct value
>>> of 1193182. (True freq is 1.193181818181...).

>> Is there any reason why you used CLOCK_TICK_RATE in some places and
>> 1193182 in others ??? I can understand your using the number in the
>> definition of CLOCK_TICK_RATE but not in the other cases.

> I only changed the numbers from 1193180 to 1193182 in the patch.
> The presence of the number instead of CLOCK_TICK_RATE in many drivers
> is most likely a bug by itself, but that'll need to be addressed in a
> different patch.
> The only one place where I fixed it for now is the pcspkr.c driver,
> since that is the one that actually started the whole thing.

>> If I'm reading it correctly, the result is a collection of bugs on the
>> AMD ELAN system as that uses a different frequency (at least, according
>> to the last but one hunk in your patch)...

> Care to send me a patch to fix this all completely and for once?

I'm not sure whether your patch was for the 2.4 or 2.5 kernels. Linus has
just released the 2.5.71 kernel which I haven't yet downloaded, but when
UI have, I'll produce a patch for that as well. Enclosed is the relevant
patch against the 2.4.21 raw kernel tree with comments here:

1. The asm-arm version of timex.h includes an arm-subarch header that
is presumably supposed to define the relevant CLOCK_TICK_RATE for
each sub-arch. However, some don't. I've included a catch-all in
timex.h that defines CLOCK_TICK_RATE as being the standard value
you've used if it isn't defined otherwise.

Note that with the exception of the catch-all I've introduced, the
various arm sub-arches all use values other than 1193182 here, so
this architecture may need further work.

2. The IA64 arch didn't define CLOCK_TICK_RATE at all, but then used the
1193182 value as a magic value in several files. I've inserted that
as the definition thereof in timex.h for that arch.

3. The PARISC version of timex.h didn't define CLOCK_TICK_RATE at all.
Other than the magic values in several generic files, it apparently
didn't use it either. I've defined it with the 1193182 value here.

This patch defines CLOCK_TICK_RATE for all architectures as far as I can
tell, so the result should compile fine across them all. I can only test
it for the ix86 arch though as that's all I have.

> Anyone disagrees with changing all the instances of 1193180/1193182 to

Other than the ARM architecture, that appears to be the value used for
all of the currently supported architectures in the 2.4 kernel series...

Best wishes from Riley.
* Nothing as pretty as a smile, nothing as ugly as a frown.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
Version: 6.0.489 / Virus Database: 288 - Release Date: 10-Jun-2003
[unhandled content-type:application/octet-stream]
 \ /
  Last update: 2005-03-22 13:36    [W:0.057 / U:9.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site