calibrating MIPS counter frequency

calibrating MIPS counter frequency

[Jun Sun]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]


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

[-- Attachment #2: calibrate_mips_counter.011128.011128.patch --]
[-- Type: text/plain, Size: 2572 bytes --]

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);
 }

Re: calibrating MIPS counter frequency

[Ralf Baechle]

On Wed, Nov 28, 2001 at 02:25:47PM -0800, Jun Sun wrote:

> 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.

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

Re: calibrating MIPS counter frequency

[Maciej W. Rozycki]

On Fri, 30 Nov 2001, Ralf Baechle wrote:

> 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.

 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: calibrating MIPS counter frequency

[Alan Cox]

>  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. :-)

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

Re: calibrating MIPS counter frequency

[Alan Cox]

>  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. :-)

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

Re: calibrating MIPS counter frequency

[Ralf Baechle]

On Thu, Nov 29, 2001 at 04:21:46PM +0100, Maciej W. Rozycki wrote:

> > 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.
> 
>  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. :-)

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

Re: calibrating MIPS counter frequency

[Jun Sun]

Ralf Baechle wrote:
> 
> On Wed, Nov 28, 2001 at 02:25:47PM -0800, Jun Sun wrote:
> 
> > 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.
> 
> 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. 

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