Subject: calibrating MIPS counter frequency

From: Jun Sun <[email-masked]>
Date: Wed, 28 Nov 2001 14:25:47 -0800

I wrote a little routine to calibrate CPU counter if the frequency is not
given by the board setup routine.  See the patch below.

Not too much use of it right now - unless you are writing some generic MIPS
performance test program.  Then you should be grateful.  It removes the board
dependency.

In the future, I think mips counter frequency really should go to mips_cpu
structure.  If we always know the counter frequency, either by board setup
routine or runtime calibration, we can get rid of the gettimeoffset
calibration routines.

Feedbacks are welcome.

Jun

Calibrate CPU counter frequency if it is not specified by board setup
routine.  No usage for now.  In the future, it should be part of
mips_cpu structure and we can get rid of the run-time gettimeoffset
calibration routines.  Should also speed timer interrupt a little bit.

Jun Sun

diff -Nru linux-2.4.14/init/main.c.orig linux-2.4.14/init/main.c
--- linux-2.4.14/init/main.c.orig	Fri Oct 12 10:17:15 2001
+++ linux-2.4.14/init/main.c	Wed Nov 28 11:18:58 2001
@@ -539,6 +539,9 @@
  *	Activate the first processor.
  */
 
+#if defined(CONFIG_MIPS) && defined(CONFIG_NEW_TIME_C)
+extern void calibrate_mips_counter(void);
+#endif
 asmlinkage void __init start_kernel(void)
 {
 	char * command_line;
@@ -581,6 +584,9 @@
 	kmem_cache_init();
 	sti();
 	calibrate_delay();
+#if defined(CONFIG_MIPS) && defined(CONFIG_NEW_TIME_C)
+	calibrate_mips_counter();
+#endif
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (initrd_start && !initrd_below_start_ok &&
 			initrd_start < min_low_pfn << PAGE_SHIFT) {
diff -Nru linux-2.4.14/arch/mips/kernel/time.c.orig linux-2.4.14/arch/mips/kernel/time.c
--- linux-2.4.14/arch/mips/kernel/time.c.orig	Mon Nov 26 18:22:58 2001
+++ linux-2.4.14/arch/mips/kernel/time.c	Wed Nov 28 13:57:23 2001
@@ -27,6 +27,7 @@
 #include <asm/time.h>
 #include <asm/hardirq.h>
 #include <asm/div64.h>
+#include <asm/debug.h>
 
 /* This is for machines which generate the exact clock. */
 #define USECS_PER_JIFFY (1000000/HZ)
@@ -505,4 +506,47 @@
 	 * Determine the day of week
 	 */
 	tm->tm_wday = (gday + 4) % 7; /* 1970/1/1 was Thursday */
+}
+
+/*
+ * calibrate the mips_counter_frequency
+ */
+#define		CALIBRATION_CYCLES		20
+void calibrate_mips_counter(void)
+{
+	volatile unsigned long ticks;
+	volatile unsigned long countStart, countEnd;
+
+	if (mips_counter_frequency) {
+		/* it is already specified by the board */
+		return;
+	}
+
+	if ((mips_cpu.options & MIPS_CPU_COUNTER) == 0) {
+		/* we don't have cpu counter */
+		return;
+	}
+
+	printk("calibrating MIPS CPU counter frequency ...");
+
+	/* wait for the change of jiffies */
+	ticks = jiffies;
+	while (ticks == jiffies);
+
+	/* read cpu counter */
+	countStart = read_32bit_cp0_register(CP0_COUNT);
+
+	/* loop for another n jiffies */
+	ticks += CALIBRATION_CYCLES + 1;
+	while (ticks != jiffies);
+
+	/* read counter again */
+	countEnd = read_32bit_cp0_register(CP0_COUNT);
+
+	/* assuming HZ is 10's multiple */
+	db_assert((HZ % CALIBRATION_CYCLES) == 0);
+
+	mips_counter_frequency = 
+		(countEnd - countStart) * (HZ / CALIBRATION_CYCLES);
+	printk(" %d Hz\n", mips_counter_frequency);
 }

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 30 Nov 2001 02:02:40 +1100

> routine or runtime calibration, we can get rid of the gettimeoffset

Better stick with the calibration procedure.  The crystal oscilators used
in most computer systems don't provide the high accuracy of frequency
that is required to keep the clock accurately over long time.  An RTC
chip which you'd probably use as reference clock is better at that so
should be used as the ultimate reference time in the kernel.

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Thu, 29 Nov 2001 16:21:46 +0100 (MET)

> should be used as the ultimate reference time in the kernel.

 On the contrary, the DECstation's undocumented I/O ASIC FCR (free running
counter) driven by the TURBOchannel bus clock is said to be much more
accurate than the DS1287 used there.  And it's David L. Mills who says so,
thus we may safely assume it's true. :-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Alan Cox <[email-masked]>
Date: Thu, 29 Nov 2001 15:34:15 +0000 (GMT)

> thus we may safely assume it's true. :-)

The old DEC hardware guaranteed good time quality. But thats rather unusual
beyond DEC.

---

From: Jun Sun <[email-masked]>
Date: Thu, 29 Nov 2001 10:17:56 -0800

Ralf Baechle wrote:
> that is required to keep the clock accurately over long time. 

The drifting clock effect won't happen here because the base value (timerlo)is
reset at each jiffies change.  So it is as accurate as your system timer, plus
minor skew within a jiffy period.

The existing calibration routines actually use the same oscilator and a
similar algorithm, except calibration is done in an "amortized" fashion.  It
will suffer the same within-jiffy skew caused by irregular osilator.

The existing code calibrates over a longer time.  So potentially it can be
more accurate.  On the other hand, the calibration routine takes a longer
time, which affects the accuracy the other way.

My current patch uses 20 jiffy cycles as the calibration period.  On ddb5476
board, the result is off by 1/100,000, which should well preserve the 1us
resolution.

It would be interesting to see the actual result from existing calibrations. 
In any case, the skews are probably so small that it won't be an issue here.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 30 Nov 2001 02:59:02 +1100

> thus we may safely assume it's true. :-)

Whooa, Master Secundus Minutius Hora himself ;-)

Actually the accuracy of crystal oscillators may differ wildly depending
on the use in a system and environmental conditions.  In case of the
SGI Indy the DS1387 RTC (which is rated at +/- 25ppm ~= 1 minute / month) is
actually more accurate.

  Ralf