Re: evbmips and MIPS3 timecounters committed

Garrett D'Amore <[email protected]>
Newsgroups gmane.os.netbsd.ports.mips.devel,gmane.os.netbsd.ports.evbmips
Message-ID <[email protected]>
Frank Kardel wrote:
> 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'll run the regression later.  My test machine has tiny memory and runs
over NFS, so I can't promise that those won't impact the results.  This
is the nature of the embedded port. :-)  But at least with a 10 second
test, sleep and /bin/time seemed to correlate and match an external
stop-watch.

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

Yes.  There isn't much there actually.  I even considered doing this in
arch/mips/, but right now the mips ports do their clock setup each
separately.  So it takes some effort (not much) to do that.

In any case, I'm just using a function to read the cp0 value which
already exists, and is implemented in fast assembly.  (I don't even need
to use a wrapper function, so there isn't even an extra call frame.  The
end result is that I think it is as fast as it can be.)

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

Sure.  :-)  That's why I'm not converting any others, even though
converting a bunch of the mips ports would _probably_ be safe.

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

>
> Thanks again for the next timecounter port.

Thanks for doing the "hard part".  :-)

    -- Garrett
>
> Frank


-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.