Hi,
Maciej W. Rozycki wrote:
Well, many platforms have some sort of external timer interrupt sources
(like an 8254 or an DS1287 or even a more sophisticated timer; sometimes
integrated in the south bridge and collecting dust there), but people tend
to follow the path of least resistance and use the CP0 timer, even though
it is is a valuable resource that may be used for some other purposes. I
Which other purposes ? CP0 hpt gives generally the highest precision for
a given platform, and it seems to be your case too. I don't see which other
better purpose it can deserve other than hrtimer, tick interrupt...
think the issue has been raised here many times already. The CP0 timer
has its problems too as it is one-shot only and needs complicated recovery
if an interrupt is missed -- see c0_timer_ack().
Well I would say that because it's one-shot, it's a good timer to choose.
I don't see how you can have hrtimer support if you choose a periodic
timer...
And missed interrupts doens't seem a big deal, and the new kernel time
subsystem handle them for us already.
Please note that this generic calibration code may be used for
calibrating the CP0 timer too -- all that you need is defining
Actually the current patchset breaks it since it changes the calibration
code to be used only for the cp0 hpt calibration. I'll change that.
mips_timer_state appropriately, i.e. to flip at the HZ rate (it may be
based on one of the south bridge choices mentioned above or some
free-running counter for example), but people seem to prefer to write
their own code for some reason. ;-)
Do you have any examples in mind which rewrite their own calibration
code ? I'm too lazy to search into all board code.
1. No HPT at all.
2. HPT in the chipset.
3. HPT in CP0.
depending on the configuration as determined at the run time, with no
predefined frequency in the cases #2 and #3.
Good to know.
And FYI for DEC CP0 is meant to be the last resort (current code does not
Again IMHO it should be the first choice if possible.
--
Franck
