diff options
| author | Lennert Buytenhek <buytenh@org.rmk.(none)> | 2005-03-21 20:47:35 +0000 |
|---|---|---|
| committer | Russell King <rmk@flint.arm.linux.org.uk> | 2005-03-21 20:47:35 +0000 |
| commit | edfb74968a4f6f6b312652760956f8fd6524924f (patch) | |
| tree | 0a970e5ff8ac1233694664cd1afe949376d68c71 /net/unix/af_unix.c | |
| parent | 7882ca4e6934b0ad113f7a80758ca8d818b08daf (diff) | |
[ARM PATCH] 2571/1: minor time-keeping fixes for ixp2000
Patch from Lennert Buytenhek
There are two very minor issues with time-keeping on the ixp2000:
1. It turns out that if T#_CLD (timer reload value) is set to X,
it means the timer will spend a full tick on 0, then a full
tick on X, and then start counting down towards 0, which then
effectively gives the timer a period of X+1 instead of the
intended X. Solve by writing X-1 instead of X to T#_CLD.
This is relatively harmless, though -- assuming a 50MHz system
clock (like on the ENP-2611) and HZ=100, there will be 500000
timer interrupts generated per 500001 real-world jiffies, but
that last timer interrupt will call timer_tick twice, taking the
system time from 499999 jiffies plus 20000 usec to 500001 jiffies
plus 0 usec. Every 500000th jiffy will 'not exist', and every
other jiffy will last 10002us instead of 10000us.
2. next_jiffy_time is initialised as '0xffffffff - ticks_per_jiffy',
but timer 4 starts ticking from 0xffffffff downwards, which will
cause the time offset in the first 1/HZ sec after timer int init
to be negative, and the first timer interrupt ever not to call
timer_tick().
Neither of these issues can cause clock drift or backwards clock
motion, but it's good to fix them nevertheless.
Signed-off-by: Lennert Buytenhek
Signed-off-by: Deepak Saxena
Signed-off-by: Russell King
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions
