Re: ptimer use of bottom-half handlers

[Peter Maydell]

On Fri, 27 Sep 2019 at 18:40, Richard Henderson
<address@hidden> 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