From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4Yr-0003Sz-KI for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:15:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv4Yl-0007q1-Bb for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:15:37 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:50650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv4Yl-0007pZ-0L for qemu-devel@nongnu.org; Wed, 08 Feb 2012 05:15:31 -0500 From: Paul Brook Date: Wed, 8 Feb 2012 10:15:25 +0000 References: <201202071128.45180.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201202081015.25639.paul@codesourcery.com> 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: Peter Crosthwaite 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 > > > 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. - When are interrupts raised. You mention a user specified match value. Do we also get an interrupt on wraparound? - 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? If you've got independent wrap and match events then I guess yes, a periodic wrap plus a oneshot match event is probably appropriate. 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. Paul