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

[Riley Williams]

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_courier-31793-1055674418-0001-2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

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, [e-mail]
 >>>   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.