Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model

From: Peter Crosthwaite <peter.crosthwaite@petalogix.com>
To: Paul Brook <paul@codesourcery.com>
Cc: peter.maydell@linaro.org, monstr@monstr.eu,
	edgar.iglesias@petalogix.com, qemu-devel@nongnu.org,
	John Linn <john.linn@xilinx.com>,
	duyl@xilinx.com, linnj@xilinx.com, afaerber@suse.de,
	john.williams@petalogix.com
Subject: Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model
Date: Wed, 8 Feb 2012 22:47:36 +1000	[thread overview]
Message-ID: <CAEgOgz4wG8jkuWZ2anmDG8HBwqZcAVmUZK7rvJmgMnZVVhvmOw@mail.gmail.com> (raw)
In-Reply-To: <201202081235.13824.paul@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2665 bytes --]