Re: clocks on mips

[email protected] wrote:

> It appears that all arc systems have a MIPS 3 clock and can handle clock
> interrupts on CP0 counter.
>  I think this is probably also true of
> hpcmips.

hpcmips also supports TX39xx machines and IIRC they are MIPS1.

> 1) convert those models that can do it to common mips3 clock code in
> mips/mips/mips3_clock.c, modulo the following comments

Maybe arc could switch (I guess soda also had the same idea),
but one concern is that clock frequencies defined in arc/arc/p_*.c
files for each platform are not confirmed, because unlike sgimips
most ARC BIOS onarc machines don't have clock frequency info.
Actually I notice it was wrong for my Express5800/230 while ago.
We should some clock measurement function like hp300/clock.c,
but I don't have good idea for it right now.

Note current interupt code in arc is a bit messed up.
I and soda always discuss that they should be reorganized, but... ;-p

> 2) this means in the short term, loss of statclock.  i propose that the
> statclock be handled by the external clocks (whatever are present) when
> they exist.  i.e. I'm suggesting that the statclock timer be the
> "optional" clock, and that the mips3_cp0_clock always be used. 
> statclock/stathz, etc. should be set up by the MD code.

statclock(9) is recommended to have some "variance" in its interval
for precise statistics (see hp300/clock.c or the Design and
implementation of 4.4BSD), so I'm not sure if we can use the existing
external clocks for it because most of them have only fixed interval.

But I don't mind just removing statclock implementations with CPU INT5
from arc since I can't see particular performance improvement with it.

BTW, current mips3_clock.c:mips3_clockintr() doesn't handle
lost clock interrupts properly. (just adjusting the next compare)
I wonder if it's worth to count how many interrupts were lost
and call hardclock(9) more than once, like current
arc/timer.c:statclockintr() and macppc/clock.c:decr_intr() do.

> 3) this probably means cleaning up mips3_clock.c somewhat -- the
> statclock needs to move out of it, and the delay() needs to rename to
> mips3_delay.
>
> 4) for systems that can just use mips3_delay as is, I would use a weak
> symbol alias so that at link time delay() is resolved to mips3_delay.
> 
> 5) I'd like to rename cpu_initclocks() to mips3_initclocks() and weak
> alias it as well.

Yeah, these are what I asked.

> 6) I'd like to move the resulting mips3_initclocks() and
> mips3_clockintr() into a new file, mips3_hardclock.c or
> mips3_clockintr.c, so that ports which for some reason can't use these
> (ews4800mips?) don't have to carry the baggage, but can still use the
> rest of the code in mips3_clock.c

Or to have some __HAVE_MIPS_NO_INT5_CLOCK or something in types.h?
(and we should get rid of options MIPS3_ENABLE_CLOCK_INTR)
---
Izumi Tsutsui