Garrett D'Amore wrote:

>Frank Kardel wrote:
>  
>
>>Garrett D'Amore wrote:
>>
[...]

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

>>[...]
>>
>>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.
>  
>
There are more constructs like that. The time pickup from the RTC chip
with the decision whether to use file system time or rtc time could be
refactored into MI. MD just needs to provide an RTC reading and setting 
function.
And that could even be refactored by using a device concept to get access to
the RTC and thus allow sharing of chip access code. (I don't know 
whether this is
the most pressing topic but it would simplfy ports again)

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

>Sure.  :-)  That's why I'm not converting any others, even though
>converting a bunch of the mips ports would _probably_ be safe.
>
>  
>
But testing helps - I missed a sun4/4c glitch last time I converted 
blindly...

[...]

>>    
>>
>>Thanks again for the next timecounter port.
>>    
>>
>
>Thanks for doing the "hard part".  :-)
>  
>
Goes to simonb@ (I think together we did it about 3-4 times)
for the port and PHK for the main core work also.

>    -- Garrett
>
Frank