On 27 June 2016 at 19:26, Dmitry Osipenko <dig...@gmail.com> wrote: > On 27.06.2016 16:27, Peter Maydell wrote: >> 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... > > In case of a polled timer that doesn't have ptimer trigger bottom half > callback > setup, we are free to wrap around counter since timer behaviour isn't changed > from ptimer user perspective, as it won't be able to change it's state in the > handler. > > I just decided to keep that wraparound feature for a case of a polled free > running timer, this should result in a better distribution of the polled > value. > The potential users of that feature are "imx_epit" and "digic" timer device > models. I should have mentioned it in the commit message to avoid confusion, > sorry. > > It is still an internal implementation detail, not sure what you are meaning. > Could you elaborate, please?
What I meant was: ptimer_get_count() is typically called to generate a value to return from a register. That's a separate thing, conceptually, from whether the device happens to also trigger an interrupt on timer expiry by passing a bh to ptimer_init(). So it's very odd for a detail of interrupt-on-timer-expiry (that there is a bottom half) to affect the value returned when you read the timer count register. thanks -- PMM
