RE: [patch] input: Fix CLOCK_TICK_RATE usage ... [8/13]

From: Riley Williams (Riley@Williams.Name)
Date: Sun Jun 15 2003 - 05:51:00 EST


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


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:41 EST