2012/2/8 Paul Brook <paul@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