From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6kA-0007e0-K6 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:35:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv6k4-0003ij-Md for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:35:26 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:33673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6k4-0003iP-IF for qemu-devel@nongnu.org; Wed, 08 Feb 2012 07:35:20 -0500 From: Paul Brook Date: Wed, 8 Feb 2012 12:35:13 +0000 References: <201202081015.25639.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201202081235.13824.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 > > - 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 :-) Paul