Izumi Tsutsui wrote:
> garrett_damore@tadpole.com 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
>   

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
>> 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.
>   

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.

    -- Garrett
> ---
> Izumi Tsutsui
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191