On 10/4/19 10:40 AM, Peter Maydell wrote:
> So we should probably cause that to happen in the new scheme
> (conceptually, something like "the trigger callback is
> implicitly considered to be called from within a tx begin/
> commit block, so (a) it doesn't need to do begin/commit itself
> and (b) i
On Fri, 27 Sep 2019 at 11:01, Peter Maydell wrote:
> The ptimer API is basically a down-counter (with a lot of bells
> and whistles), with functions to do things like "read current count"
> and "write current count". When the counter hits zero it typically
> reloads, and the ptimer code notifies a
On Fri, 27 Sep 2019 at 18:40, Richard Henderson
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_transac
On 9/27/19 3:01 AM, Peter Maydell wrote:
> (2) call the device's callback function directly when the
> ptimer triggers from the QEMU timer expiry. But for
> the case of "a call to ptimer_set_count() etc caused
> the timer to trigger", don't call the callback, instead
> return a
Investigating https://bugs.launchpad.net/qemu/+bug/177 I
found what seems to be a design flaw in the ptimer code.
The ptimer API is basically a down-counter (with a lot of bells
and whistles), with functions to do things like "read current count"
and "write current count". When the counter hit
