qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v8 2/4] hw/ptimer: Perform tick and counter wrap a


From: Dmitry Osipenko
Subject: Re: [Qemu-arm] [PATCH v8 2/4] hw/ptimer: Perform tick and counter wrap around if timer already expired
Date: Wed, 6 Jan 2016 23:52:11 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

06.01.2016 16:59, Peter Crosthwaite пишет:

+
+            if (expired) {
+                /* Wrap around periodic counter.  */
+                counter = s->delta = s->limit - counter % s->limit;


Why do you update the delta here?


Because we would want to schedule next tick based on current wrapped around
counter value and not some arbitrary delta.


So looking at ptimer_reload(), the new schedule is done relative to
the VM clock of the when the tick was expected to hit, not the current
time. But this new delta is going to be relative to the now time and
then used to update the next tick which will happen relative to
next_event. Unless you stop or scale the timer, I don't think you need
to do delta manipulation?


Yes, I missed that next_event would be set earlier (like you described) in case of expired timer. Thanks for the note, will fix it.

Also can you just get ptimer_reload to do the modulo math for you? If the
timer is !oneshot and expired, then you call ptimer_reload anyway,
which will update next_event. When the expired test returns false
you can just reliably use the original logic involving now and next.


Yes, that's what I changed in V9. Have you received it?

https://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00272.html


Just had a look.

V9 still has the modulo I think?:

+            if (expired && (counter != 0)) {
+                /* Wrap around periodic counter.  */
+                counter = s->delta = s->limit - counter % s->limit;
+            }


Modulo is there, I just meant that V9 changed to call ptimer_reload() on counter == 0. As noted above, ptimer_reload would adjust next_event, so s->delta shouldn't be set to the wrapped around counter. However it should be set to the limit, since delta might been altered by ptimer_set_count.

--
Dmitry



reply via email to

[Prev in Thread] Current Thread [Next in Thread]