2012/2/8 Paul Brook <p...@codesourcery.com> > > > - 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.
> Paul > Peter
