Subject: separate statclock of footbridge (Re: CVS commit: syssrc/sys/arch/arm/footbridge)
To: None <email@example.com>
From: Izumi Tsutsui <firstname.lastname@example.org>
Date: 10/27/2002 23:03:42
In article <20021005122256.17949B42C@cvs.netbsd.org>
> Module Name: syssrc
> Committed By: chris
> Date: Sat Oct 5 12:22:55 UTC 2002
> Modified Files:
> syssrc/sys/arch/arm/footbridge: footbridge_clock.c
> Log Message:
> Add random jitter to stat clock, the random jitter is +- 511 usec's, so
> we should average the nominal clock rate.
In this change, it seems statprev is not initialized properly
so it would cause random overruns. Is this patch Ok?
RCS file: /cvsroot/syssrc/sys/arch/arm/footbridge/footbridge_clock.c,v
retrieving revision 1.13
diff -u -r1.13 footbridge_clock.c
--- footbridge_clock.c 2002/10/10 23:19:13 1.13
+++ footbridge_clock.c 2002/10/27 13:47:08
@@ -244,7 +244,8 @@
/* statint == num in counter to drop by desired hz */
- statint = clock_sc->sc_statclock_count = load_timer(TIMER_2_BASE, hz);
+ statint = statprev = clock_sc->sc_statclock_count =
+ load_timer(TIMER_2_BASE, hz);
/* Get the total ticks a second */
countpersecond = statint * hz;
> stathz now runs at hz (the hard clock hz), without getting high amounts of
> time in interrupt handling.
BTW, it seems this code is taken from hp300/clock.c,
but why does `adding random jitter' solve the problem?
If the problem is caused by conflicts of clockhandler() and
statclockhandler(), isn't it enough to add some delay (~5ms)
before initializing TIMER_2 after TIMER_1 is started?