Re: evbmips and MIPS3 timecounters committed
Frank Kardel <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.ports.evbmips |
|---|---|
| Message-ID | <[email protected]> |
Garrett D'Amore wrote: >Frank, > >I've committed evbmips support for timecounters using >mips3_cp0_counter. It was fairly trivial. It _looks_ good so far, but >if you have any suggestions I'd love to hear them. > > Great ! Glad to hear that it was reasonably easy. Could you run the sleep regression test to see whether the relation between clock interrupt handling and counter reading stays in a reasonable relationship. (cd regress/sys/kern/sleeping && make regress) on an unloaded machine (scheduling/paging can make the test fail). >I'm CC'ing the evbmips crowd on this, and the port-mips crowd, because >they might want to borrow the logic. It is pretty much the same way on >any MIPS3 class cpu. > > > Would it be possible to refactor the part for all mips 3 based ports? >I've only tested AR5312, but it was done in evbmips common code, so I >expect it will just work everwhere. > >Btw, I looked at kern_clock.c -- it will be really, really nice to >eliminate the legacy support once we get the other ports committed. > > > Yes - I'd like to do the unifdef run rather sooner than later but that depends a bit on the ports converting (no news). Blind conversions (It compiles - ship it!) are in my experience a bit risky - things are very easy to mess up. >Sample output: > >nano# sysctl -a | grep timecount >kern.timecounter.choice = mips_cp0(q=0, f=110000000 Hz) >clockinterrupt(q=0, f=100 Hz) dummy(q=-1000000, f=1000000 Hz) >kern.timecounter.hardware = mips_cp0 >kern.timecounter.timestepwarnings = 0 > > > - Garrett > > > I marked the switch on http://www.kardel.name/timecounters-status.html which also contains the analysis what work ist left to do for the ports (including re-factoring hints). Thanks again for the next timecounter port. Frank