Separate time support for using cpu timer

Background
----------

The current arch/mips/kernel/time.c has been stretched over the time such that it now looks like a convoluted spaghetti to me:

1) it was originally designed to be flexible so that we could support all imaginable timer sources and timer setups:
. use cpu timer (count/compare pair)
. use board timer, with cpu count and known frequency . use board timer, with cpu count and unknown frequency . use board timer, with cpu count and unknown frequency, and
we can use 64bit division
. jiffy interrupt through do_IRQ
. jiffy interrupt through ll_timer_interrupt
.....

2) introduction of 32bit SMP causes more complexity

3) the hpt_xxx stuff introduces another abstraction layer between hw timer (where cpu timer is treated as one kind of hw timers) and the time subsystem.

Solution
--------

All the boards that I am really concerned right now have cpu count/compare registers. I believe this will even more so in the future.

Therefore I like to propose a separate time support for systems that use cpu timer as their system timer.

As you can see from the patch, the new code is much simpler.

The hidden agenda
-----------------

OK, I admit there is another motivation in all of this. Linux is moving to have higher resolution timer. For example, see the introduction of high resolution posix timer (http://sourceforge.net/projects/high-res-timers/). Having a MIPS common time routine based on cpu timer makes it much easier to support
such a feature for MIPS boards. We don't need to mess with individual board timer anymore.

In addition I think in 2.7 time frame Linux needs to replace its ancient jiffy time system with a natively higher resolution time system. A MIPS cpu timer based routine would evolve much better into the future.

The patch
---------

The attached is the patch for UP case. I will post an additional patch for SMP case later.

The patch is currently designed to be drop-in replace for arch/mips/kernel/time.c. As you can see from the patch, you will only need to modify the Kconfig to define CPU_TIMER for the qualified boards.

Comments?

Jun

diff -Nru linux/arch/mips/Kconfig.orig linux/arch/mips/Kconfig
@@ -320,6 +320,7 @@
 config DDB5477
 	bool "Support for NEC DDB Vrc-5477"
 	select IRQ_CPU
+	select CPU_TIMER
 	help
 	  This enables support for the R5432-based NEC DDB Vrc-5477,
 	  or Rockhopper/SolutionGear boards with R5432/R5500 CPUs.

@@ -516,6 +517,7 @@
 config SIBYTE_SWARM
 	bool "BCM91250A-SWARM"
 	select SIBYTE_SB1250
+	select CPU_TIMER
 
 config SIBYTE_SENTOSA
 	bool "BCM91250E-Sentosa"

@@ -800,6 +802,13 @@
 	  byte order. These modes require different kernels. Say Y if your
 	  machine is little endian, N if it's a big endian machine.
 
+config CPU_TIMER
+	bool
+	help
+	  If CPU has count/compare registers (most do), and they are used
+	  as system timer, you can say 'Y' here to use the alternative
+	  time routines.
+
 config IRQ_CPU
 	bool
 

diff -Nru linux/arch/mips/kernel/Makefile.orig linux/arch/mips/kernel/Makefile
@@ -6,7 +6,13 @@
 
 obj-y		+= cpu-probe.o branch.o entry.o genex.o irq.o process.o \
 		   ptrace.o reset.o semaphore.o setup.o signal.o syscall.o \
-		   time.o traps.o unaligned.o
+		   traps.o unaligned.o
+
+ifdef CONFIG_CPU_TIMER
+obj-y				+= cpu-timer.o
+else
+obj-y				+= time.o
+endif
 
 ifdef CONFIG_MODULES
 obj-y				+= mips_ksyms.o

diff -Nru linux/arch/mips/kernel/proc.c.orig linux/arch/mips/kernel/proc.c
@@ -78,7 +78,9 @@
 	[CPU_SR71000]	"Sandcraft SR71000"
 };
 
-
+#if defined(CONFIG_CPU_TIMER)
+extern int missed_timer_count;
+#endif
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
 	unsigned int version = current_cpu_data.processor_id;

@@ -121,6 +123,10 @@
 	seq_printf(m, fmt, 'D', vced_count);
 	seq_printf(m, fmt, 'I', vcei_count);
 
+#if defined(CONFIG_CPU_TIMER)
+	seq_printf(m, "missed timers\t\t: %d\n", missed_timer_count);
+#endif
+
 	return 0;
 }
 

It makes it separate again -- more maintenance burden and a bigger
opportunity to have functional divergence, sigh...

Additionally I don't think using the CP0 Count & Compare registers for
the system timer is the way to go. It's rather a way to escape when there's no other possibility. A lot of systems have a reliable external timer interrupt source and using it actually would free the CP0 registers for other uses, like profiling or a programmable interval timer.

Well, I don't think the two issues are coupled together, although, there
may be certain dependencies. E.g. an external time source may actually have a good resolution.

Anyway, the details may be worth discussing when 2.7 spins off,
preferably on the LKML, as this is about generic support.

Maciej

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

Pretty much true for lots of improvement we made in the past a couple of years .... :)

I was rather neutral on this point until I started to add HRT/VST support to MIPS. When adding such features you really just want one common timer code. And the best choice for MIPS is cpu timer.

BTW, I plan to submit MIPS/HRT support based on the cpu-timer patch. Hopefully this will catch more attention to the cpu timer patch....

Jun

I must admit I would prefer a separate timer module. For instance, on the IP30 there is a very convenient HEART timer available, and I don't see a case for wasting a core-synchronized CPU timer (which proved indispensable during my reverse engineering of the ARCS PROM, as you can't breakpoint-debug a PROM) for the purpose of not-necessariliy-synchronized timing.

Stanislaw Skowronek

--<=>--
Paranoid: one who is truly in touch with reality.

Hmm, s/improvement/hacks/, perhaps?

Well, with the _hpt_ abstraction layer you have one common timer code,
regardless of the actual timer hardware used. If there's some functionality you miss there, we may discuss about possible solutions.

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

Current high resolution timer code calls for two logic timers, one for the old jiffy timer and one for intra-jiffy timer interrupt.

Even if you can extend hpt interface to accomondate this, each board would still end up implementing a lot of complex code.

With cpu timer, however, we can "multiplex" the same timer to emulate both logical timers. All boards using cpu timer can have HRT without any code change.

Jun