Hi Greg,
I need a flag for the TSC stuff that allows me to turn it off completely (the
voyagers run CPUs from physically different clocks, and TSC drift causes huge
jitters in this case).
How about two compile options:
CONFIG_X86_TSC meaning check for TSC and use it if it's OK
CONFIG_X86_PIT meaning use the PIT timer if the TSC isn't OK (or isn't wanted)
That way, arch's that know the TSC is OK in every case have
CONFIG_X86_TSC y
CONFIG_X86_PIT n
Arches that aren't sure if the TSC will be OK or not have
CONFIG_X86_TSC y
CONFIG_X86_PIT y
and arches that really don't want it at all have
CONFIG_X86_TSC n
CONFIG_X86_PIT y
The attached patch does all this. (I've also put it up on bkbits at
http://linux-voyager.bkbits.net/timer-2.5).
James
P.S. what about this CONFIG_X86_CYCLONE thing? It doesn't seem to be hooked
into the timer infrastructure, should it be?
> I need a flag for the TSC stuff that allows me to turn it off completely
> (the
> voyagers run CPUs from physically different clocks, and TSC drift causes
> huge
> jitters in this case).
>
> How about two compile options:
>
> CONFIG_X86_TSC meaning check for TSC and use it if it's OK
> CONFIG_X86_PIT meaning use the PIT timer if the TSC isn't OK (or isn't
> wanted)
Hmmm. I was thinking of possibly doing something similar to the 2.4
CONFIG_X86_HAS_TSC and CONFGI_X86_TSC_DISABLE, but I believe Linus
wasn't super happy about negative config options. You're usage sounds
reasonable, but since this is a cleanup item, do you mind if we both
look at the issue a bit more next week?
> P.S. what about this CONFIG_X86_CYCLONE thing? It doesn't seem to be
> hooked
> into the timer infrastructure, should it be?
Not right this second. I'm waiting for the summit subarch code to
stabilize, then I'll hook it in correctly.
thanks
-john