Messages in this thread | | | From | "Riley Williams" <> | Subject | RE: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13] | Date | Sun, 15 Jun 2003 11:51:00 +0100 |
| |
Hi.
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, vojtech@suse.cz >>> 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 > CLOCK_TICK_RATE?
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 (http://www.grisoft.com). Version: 6.0.489 / Virus Database: 288 - Release Date: 10-Jun-2003 [unhandled content-type:application/octet-stream] | |