clocks on mips
Garrett D'Amore <[email protected]> Fri, 08 Sep 2006 09:02:13 -0700
| Newsgroups | gmane.os.netbsd.ports.hpcmips,gmane.os.netbsd.ports.arc,gmane.os.netbsd.ports.mips.devel |
|---|---|
| Message-ID | <[email protected]> |
I've been looking at arc. 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. For pmax and company, it is probably true for _some_ models. I'd like to recommend the following: 1) convert those models that can do it to common mips3 clock code in mips/mips/mips3_clock.c, modulo the following comments 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. 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. 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 Thoughts? -- 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