On Thu, 14 Jun 2007, Franck Bui-Huu wrote:
> > Which should normally be the case unless there is no way to do
> > calibration, when a platform can provide a hardcoded value. There is
> > nothing to guess here.
> Are you sure it's the normal case? I would say that only DEC needs
> that calibration:
> Doing the following on the _current_ tree:
> $ git grep -l mips_timer_state arch/mips
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
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().
Please note that this generic calibration code may be used for
calibrating the CP0 timer too -- all that you need is defining
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. ;-)
> > 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
get it exactly right, I know -- I forgot to look at it at some point) as
there is exactly one platform that has no HPT in the chipset and uses an
R4k processor at the same time (the 5000/150 for those that care -- the
free-running counter was added in a later revision of the IOASIC). All
the others either have a HPT in the chipset or only support R3k-class
processors with no CP0 timer.