On Fri, 27 Sep 2019 at 18:40, Richard Henderson
<richard.hender...@linaro.org> wrote:
> If "other things" are being changed along with ptimer_set_count, then is the
> boolean result of ptimer_set_count necessarily still relevant after the "other
> things"?
>
> Can we record the set of things to be done within a
> ptimer_transaction_{begin,commit}() pair and then invoke the callback (if
> necessary) when committing? Is it even easy to see the set of "other things"
> that would need to be wrapped?
That seems like a good plan. The calls into the ptimer that can
cause the trigger function to be called are:
ptimer_set_count
ptimer_set_period
ptimer_set_freq
ptimer_set_limit
ptimer_run
ie all the functions which set ptimer state plus ptimer_run which
sets the timer to enabled. In all those cases what we end up doing
is something like:
if (s->enabled) {
s->next_event = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
ptimer_reload(s, 0);
}
(and ptimer_reload() recalculates the timer parameters and might end
up calling the device's trigger function).
So we could instead postpone the whole
s->next_event = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
ptimer_reload(s, 0);
to the transaction-commit function.
This would actually somewhat simplify users like the
cmsdk_dualtimermod_write_control() function, which currently have
to be a bit careful about the ordering of ptimer_run/ptimer_stop
calls relative to the other state-setting functions.
thanks
-- PMM
