[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of devi
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 2/4] cadence_ttc: initial version of device model |
Date: |
Wed, 8 Feb 2012 12:35:13 +0000 |
User-agent: |
KMail/1.13.7 (Linux/3.1.0-1-amd64; KDE/4.6.5; x86_64; ; ) |
> > - 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
[Qemu-devel] [RFC PATCH v2 3/4] cadence_gem: initial version of device model, Peter A. G. Crosthwaite, 2012/02/07
[Qemu-devel] [RFC PATCH v2 4/4] xilinx_zynq: machine model initial version, Peter A. G. Crosthwaite, 2012/02/07
Re: [Qemu-devel] [RFC PATCH v2 0/4]Zynq-7000 EPP platform model, Paul Brook, 2012/02/07