On 25 June 2016 at 13:35, Dmitry Osipenko <dig...@gmail.com> wrote:
> Software should see timer counter wrap around only after IRQ being triggered.
> Change returned counter value to "1" for the expired timer and avoid returning
> wrapped around counter value in periodic mode for the timer that has
> bottom-half
> handler setup, assuming it drives timer IRQ.
>
> This fixes regression introduced by the commit 5a50307 ("hw/ptimer: Perform
> counter wrap around if timer already expired") on SPARC emulated machine as
> reported by Mark Cave-Ayland.
>
> Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
> ---
> hw/core/ptimer.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/hw/core/ptimer.c b/hw/core/ptimer.c
> index 05b0c27..8006442 100644
> --- a/hw/core/ptimer.c
> +++ b/hw/core/ptimer.c
> @@ -93,10 +93,10 @@ uint64_t ptimer_get_count(ptimer_state *s)
> bool oneshot = (s->enabled == 2);
>
> /* Figure out the current counter value. */
> - if (s->period == 0 || (expired && (oneshot || use_icount))) {
> + if (expired && (oneshot || use_icount || s->bh != NULL)) {
> /* Prevent timer underflowing if it should already have
> triggered. */
> - counter = 0;
> + counter = 1;
> } else {
> uint64_t rem;
> uint64_t div;
I guess this fixes a regression, but it looks really weird.
Why should the timer behaviour change if there happens to be
a bottom half present? That should be an internal implementation
detail. It's also a bit odd that use_icount is in the check:
that shouldn't generally affect device emulation behaviour...
thanks
-- PMM
