[RFC] Event timers on MIPS

[Jayachandran C.]

On Sat, Jul 17, 2010 at 7:19 PM, Alexander Motin <mav at freebsd.org> wrote:
> Jayachandran C. wrote:
>> 2010/7/17 Alexander Motin <mav at freebsd.org>:
>>> I've made a patch, updating MIPS timer code (except RMI) to utilize new
>>> MI event timer infrastructure. I've successfully built QEMU and XLR
>>> kernels with the patch. Unluckily I can't test how it works, unless
>>> somebody teach me how to cook QEMU to run it. I also haven't ported RMI
>>> timers drivers, as I am not sure how that hardware is intended to work.
>>>
>>> Patch for HEAD can be found here:
>>> http://people.freebsd.org/~mav/timers_mips.patch
>>>
>>> Could somebody falimiar with MIPS review/test my patch and extend it to
>>> RMI hardware?
>>
>> XLR uses an on-chip PIC clock (running at 66MHz) for cpu 0 and
>> count/compare clock (running at CPU freq) for the other CPUs, hope
>> this is supported with the new code.
>
> I suppose that one type of timers should run on all CPUs (either one
> timer per CPU, or one timer for all of them + IPI for distribution).
> Theoretically you can implement "single" per-CPU timer implemented in
> different fashion for different CPUs, though I don't understand why it
> is needed. If these timers are independent, I would register every of
> them as-is: on-chip PIC clock as global timer (infrastructure will
> automatically manage rebroadcasting it's events via IPIs) and per-CPU
> comparators as another per-CPU timer. This give independent hardclock
> and statclock for less aliased time accounting.
>
>> Other than that, I should be able to merge the code into XLR specific
>> rmi/tick.c rmi/clock.c, if it works on other MIPS platforms.
>
> rmi/tick.c looks somewhat strange to me, registering timecounter with
> the same "MIPS32" name, but with different meaning.

On XLR we would like to use the count/compare which is faster but less
accurate on all cpus - we can have upto 32 cpus now.  We also have a
PIC which can provide a better timestamp and timer interrupts.  This
PIC timestamp can be read from all CPUs but the timer interrupt can be
delivered to just one CPU at a time.  I think this is how we ended up
with the current implementation, but any suggestions on how to improve
this is welcome.

Thanks,
JC.