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
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
posix timer (http://sourceforge.net/projects/high-res-timers/). Having a MIPS
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
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
routine would evolve much better into the future.
The attached is the patch for UP case. I will post an additional patch for SMP
The patch is currently designed to be drop-in replace for
As you can see from the patch, you will only need to modify the Kconfig to
CPU_TIMER for the qualified boards.
Description: Text document