From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38302) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4sM-0006SI-Kv for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:35:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv4sD-0003EY-SM for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:35:46 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:49955) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4sD-0003ET-HM for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:35:37 -0500 Received: by bkue19 with SMTP id e19so176198bku.4 for ; Wed, 08 Feb 2012 02:35:36 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <201202081015.25639.paul@codesourcery.com> References: <201202071128.45180.paul@codesourcery.com> <201202081015.25639.paul@codesourcery.com> Date: Wed, 8 Feb 2012 20:35:35 +1000 Message-ID: From: Peter Crosthwaite Content-Type: multipart/alternative; boundary=000e0cdfc786b8ce4904b87174c0 Subject: Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: peter.maydell@linaro.org, monstr@monstr.eu, edgar.iglesias@petalogix.com, qemu-devel@nongnu.org, John Linn , duyl@xilinx.com, linnj@xilinx.com, afaerber@suse.de, john.williams@petalogix.com --000e0cdfc786b8ce4904b87174c0 Content-Type: text/plain; charset=ISO-8859-1 2012/2/8 Paul Brook > > > > Implemented cadence Triple Timer Counter (TCC) > > > > > > It looks like you're implementing a periodic timer as sequence of > chained > > > oneshot timers. This is a bad idea. In qemu interrupt latency may be > > > high, > > > so you're likely to suffer from significant time skew. > > > > > Ok, I could implemented the wraparound event as a periodic timer and the > > match events are kicked off as seperate one-shot timers when the wrap > > around occurs? There would still be a small delay on match events, but it > > would get rid of the integration effect of lots of little delays (over > many > > wrap arounds) add up to a significant skew. > > I'm not sure why you need the oneshot timers at all. But then again I'm not > really sure what the desired semantics are either :-) > It would help me if you could describe how these timers operate. > In particular: > > - Are they free running. i.e. keep counting until explicitly stopped by > the > user, or stop when an event occurs. > Free running > - 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. > - What happens when the timer hits the limit (zero if count-down, match > value > if count-up)? Does it wrap? or load a fixed value? > > Either wrap or load a fixed value, there is a control bit to determine which. > 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. > If wrapping does not generate an interrupt, or wrap and match are > effectively > the same thing then you just need to transpose the counter onto a single > periodic timer. > > If the timers can be configured in both periodic and oneshot modes, then > you > may want to have different implementations based on that. > > I dont think this will be needed, the match mechanism detail above is more of an issue and is the underlying reason for the one shot chaining implementation. > Paul > Peter --000e0cdfc786b8ce4904b87174c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/2/8 Paul Brook &l= t;paul@codesourcery.com>
> > > Implemented cadence = Triple Timer Counter (TCC)
> >
> > It looks like you're implementing a periodic timer as sequenc= e of chained
> > oneshot timers. =A0This is a bad idea. =A0In qemu interrupt laten= cy may be
> > high,
> > so you're likely to suffer from significant time skew.
> >
> Ok, I could implemented the wraparound event as a periodic timer and t= he
> match events are kicked off as seperate one-shot timers when the wrap<= br> > around occurs? There would still be a small delay on match events, but= it
> would get rid of the integration effect of lots of little delays (over= many
> wrap arounds) add up to a significant skew.

I'm not sure why you need the oneshot timers at all. But th= en again I'm not
really sure what the desired semantics are either :-)
=A0
It would help me if you could describe how these timers operate.
In particular:

- Are they free running. =A0i.e. keep counting until explicitly stopped by = the
user, or stop when an event occurs.

Fre= e running
=A0
- When are interrupts raised. =A0You mention a user specified match value. = =A0Do
we also get an interrupt on wraparound?

Yes, an interrupts occur on wrap around of the 16 bit timer value. There a= re three match registers which correspond to three more =A0(separately=A0ma= skable) interrupts which are risen when the timer crosses that value. My im= plementation 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 wra= pping.
=A0
- What happens when the timer hits the limit (zero if count-down, match val= ue
if count-up)? Does it wrap? or load a fixed value?

Either wrap or load a fixed value, there is a control= bit to determine which.
=A0
If you've got independent wrap and match events then I guess yes, a per= iodic
wrap plus a oneshot match event is probably appropriate.


Yes this is the case. I will look into= making it happen.
=A0
If wrapping does not generate an interrupt, or wrap and match are effective= ly
the same thing then you just need to transpose the counter onto a single periodic timer.
=A0


I dont think this will be needed, the match mechanis= m detail above is more of an issue and is the underlying reason for the one= shot chaining implementation.
=A0
Paul

Peter
--000e0cdfc786b8ce4904b87174c0--