Incorrect CLOCK_TICK_RATE in 2.6 kernel

[George Anzinger <george@mvista.com>]

CLOCK_TICK_RATE	is used by the kernel to compute LATCH, TICK_NSEC and 
tick_nsec.  This latter is used to update xtime each tick.  TICK_NSEC is 
then used to compute (at compile time) the conversion constants needed 
to convert to/from jiffies from/to timespec and timeval (and others).

The problem is that, if the timer being used is either Cyclone or HPET, 
the wrong CLOCK_TICK_RATE is used.  This means that systems using these 
interrupt sources will be doing a) incorrect update of xtime and b) 
incorrect conversion of jiffies.  Since these two values will track each 
other this will not be seen by simple gettimeofday(); 
sleep();gettimeofday() tests, but will be seen as a system clock drift 
(without NTP) or with NTP, a somewhat high drift rate (to the point of 
loosing sync at HZ=1000).

The fact that the user/ system chooses the clock to use at boot time and 
can change the clock after boot means that it is not possible to pin 
down CLOCK_TICK_RATE at compile time.  However, since the computation of 
TICK_NSEC and the conversion constants is rather involved it is clear 
that we REALLY do want to compute these at compile time.

The suggested solution is to a) set up a structure with the default 
(clock of choice at config time) conversion constants in it at compile 
time.  Then b) at clock init time, populate the structure with the 
proper constants for the given clock.  These can be computed at compile 
time, but from the correct  CLOCK_TICK_RATE for the given clock. 
Switching to a fall back clock would also require an update of this 
structure.

Commits?
-- 
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/