|
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.htmlJust 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
[Prev in Thread] | Current Thread | [Next in Thread] |