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: >Simon Burge wrote: > > >>Garrett D'Amore wrote: >> >> >> >>>Frank Kardel wrote: >>> >>> >>> >>>>Garrett D'Amore wrote: >>>> >>>> >>>> >>>> >>>>>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. >>> >>> >>> >>I think we can put the core of the TC implementation in arch/mips, and >>then leave the rest in the per-port clock setup. It's only a small >>chunk of code, but I think it's better to have a small .c file in >>arch/mips than exactly the same chunk of code duplicated over all MIPS >>ports that have MIPS3 or greater CPUs. >> >> >> > >Concur. > > > >>I also think we might be better of using "mips_cp0_count" or similar for >>the timercounter name. We're using only part of the CP0 register space. >> >> >> > >I agree with that. Are there any length limitations on the name? > > yes - not for functionality but the sysctl interface implementation. It's not completely clean right now (will fix that) but not as risky as the fbsd version (sprintf(!)). timetc.h will contain a #define MAX_TCNAMELEN 64 when I check in - probably tonight ~22:00 UTC). currently names up to 12 characters should be fine. >>Simon. >> >> >> Frank