Re: Strange macros set HZ value for timer channel zero

george anzinger (george@mvista.com)
Fri, 17 Aug 2001 14:13:38 -0700


george anzinger wrote:
>
> "Richard B. Johnson" wrote:
> >
> > To whomever maintains the timer code, greetings.
> >
> > When using Linux on the AMD SC520 chip, the system time will
> > not be correct because the PIT clock is 1.1882 MHz instead of
> > the usual 1.19318 MHz. Therefore, I put a conditional value
> > in ../linux/include/asm/timex.h .
> >
> > #ifndef _ASMi386_TIMEX_H
> > #define _ASMi386_TIMEX_H
> >
> > #include <linux/config.h>
> > #include <asm/msr.h>
> > #ifdef SC520
> > #define CLOCK_TICK_RATE 1188200 /* Underlying HZ */
> > #else
> > #define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
> > #endif
> >
> > Something is wrong! I now gain 3 hours in a 12 hour period. There
> > are some calculations performed somewhere that result in the
> > wrong divisor for the timer (PIT). I don't understand any of the
> > SHIFT stuff, nor FINE_TUNE stuff. It all seems bogus although
> > it might be the "new math" that's biting me.
> >
> > The correct value for 100 Hz should be 1188200/100 = 11882 = 0x2e6a
> > for the divisor. If I hard-code the value as a divisor in
> > /usr/src/linux/arch/i386/kernel/i8259.c, it works. If I use the
> > #defines and macros in the headers, it doesn't.
> >
> Seems hard to believe. Try this:
>
> cd ../arch/i386/kernel
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.7-hr/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -march=i586 -c -o i8259.o
> i8259.c -E
>
> (note the -E, the rest of the line is just cut from the make output, I
> usually make from a shell in emacs so all this output is available...
> If you are cutting this line from this message, make sure you change the
> -I path to match your kernel location.)
>
> now exit i8259.c and search for your new number, i.e. 118820. (Or if
^^^^ gosh, that should be "edit", don't know who grabbed my
fingers there...
> that fails search for "init_IRQ" and look at the outb_p in there.) For
> the old 1192180 I find:
>
> outb_p(0x34,0x43);
> outb_p(((1193180 + 100 /2) / 100 ) & 0xff , 0x40);
> outb(((1193180 + 100 /2) / 100 ) >> 8 , 0x40);
>
> Seems like the new number should do just what you need here. The
> calibration in time.c is a little wonky, but that will not give the
> errors you are seeing, nor would your change of LATCH (I assume this is
> what you changed in i8259.c) affect that wonky stuff.
>
> Oh, by the way, you will want to purge i8259.o as make will assume it is
> up to date and try to merge it as a *.o file, which will fail rather
> badly.
>
> George
> -
> 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/
-
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/