Re: [Qemu-arm] [PATCH v17 00/14] PTimer fixes/features and ARM MPTimer conversion

[Dmitry Osipenko <digetx@gmail.com>]

On 24.10.2016 15:23, Peter Maydell wrote:
> On 2 October 2016 at 16:53, Dmitry Osipenko <digetx@gmail.com> wrote:
>> Hello,
>>
>> Currently, QEMU ARM MPTimer device model provides only a certain subset of
>> the emulation behavior. This patch series is supposed to add missing parts by
>> converting the MPTimer to use generic ptimer helper. It fixes some important
>> ptimer bugs and provides new features that are required for the ARM MPTimer.
>>
>> WARNING! I based V17 on top of the Paolo's patch [0], however I don't see
>> the original mail of that patch on the ML nor in patches/patchew.
>>
>> [0] https://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg06734.html
> 
> Looking at the code we end up with in ptimer, we seem to do an
> awful lot of adding and subtracting 1 everywhere. That makes me
> wonder if we're missing a simplification which would collapse
> all of those out (it seems unlikely that hardware would really
> ever want some of the policy flags but not all of them, since
> I think they boil down to "timer==0 is a real one-timer-cycle
> lump of time").
> 

The "timer==0 is a real one-timer-cycle lump of time" is handled by the
"wraparound after one period" policy. "no counter round down" policy, probably,
could be used by default, but we wanted to keep the old ptimer behaviour
untouched. The rest of the policies handle running with/setting counter to 0
cases, I'm not sure that all timers share same behaviour for those cases. There
is always a room for improvement :)

> That said, I think the behaviour is right and this patchseries has
> been around way too long already, so I've applied it to target-arm.next.
> If we can think of a simplification we can always apply it later
> as a refactoring with a fair degree of confidence given the tests...
> 

Yay! That took a while. Now we can move to the next ptimer issue, like
period/freq change glitch :)

-- 
Dmitry