Subject: Re: clocks on mips
To: Izumi Tsutsui <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 09/08/2006 09:54:05
Izumi Tsutsui wrote:
> firstname.lastname@example.org 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 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
Malta currently does this. A realtime clock (if present) can be used to
set the cpu freq in MD code. If you don't have _any_ real-time
reference, then you're hosed anyway.
>> 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.
Agreed. statclock() is optional anyway. The issue is that you want to
avoid aliasing the cpu clock and the statclock. With MIPS3 cp0 counter,
if this is a problem, one can just adjust HZ for the port. (I.e. the
cp0 counter is still used, but we write a different value into cp0_compare.
> 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.
I'll take a look at it.
>> 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
>> 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.
I know. Its time to clean it up now. I'm offering to do so.
>> 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)
Maybe. I don't know. For now putting it in a separate file seems
cleaner than having more garbage in types.h. But that's just my opinion.
> Izumi Tsutsui
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191