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