> > - When are interrupts raised. You mention a user specified match value.
> > Do we also get an interrupt on wraparound?
>
> Yes, an interrupts occur on wrap around of the 16 bit timer value. There
> are three match registers which correspond to three more
> (separately maskable) interrupts which are risen when the timer crosses
> that value. My implementation will figure out which of the three events (or
> the wraparound) will occur next, and one shot the corresponding period of
> time. Note that a match can occur an raise an interrupt without a wrap or
> reset occuring. E.G. i could set my timer counting up from 0 and when the
> value hits BEEF, i get an interrupt, but the timer still counts all the way
> to FFFF before wrapping.
Ok. I'd missed that there are 3 matches per timer.
> > If you've got independent wrap and match events then I guess yes, a
> > periodic
> > wrap plus a oneshot match event is probably appropriate.
>
> Yes this is the case. I will look into making it happen.
It's probably not worth using ptimer at all.
Instead use QEMUTimer/qemu_mod_timer directly. The trick is to call
qemu_get_clock_ns when the timer is started and calculate all deadlines
incrementally from that, not from the time when the last timeout happened to
fire. See ptimer.c:ptimer_reload/tick or stellaris.c:gptm_reload/tick for
examples.
ptimer.c provides a common implementation of a simple periodic timer.
Previously we had a dozen different implementations, most of which were broken
in one way or annother. For more complicated devices you need to know what
you're doing anyway :-)
Ok, this would lead to a more minimal change then :). Just replace ptimer with QEMUTimer and stick with the incremental deadlines approach which is pretty much the code is as it stands.