[PATCH] Correct a race condition between the e500 core decrementer wrapping and the tick interrupt being handled

[Sebastian Huber]

On 10/12/14 02:53, Nick Withers wrote:
> On Wed, 2014-12-03 at 08:09 +0100, Sebastian Huber wrote:
>> Hello Nick,
>>
>> to disable TCR[ARE] is not the right fix.  You have to check the
>> TSR[DIS] register in the nanoseconds extension.  See for example
>> lpc-clock-config.c for an example.
> Hi Sebastian,
>
> Thanks for your help, 'fraid I need to lean on you a little more...
>
> I don't understand how the proposed solution (or that in
> lpc-clock-config.c) can work properly in the case where the nanoseconds
> extension could be queried multiple times with an interrupt lock held
> (which I believe disables interrupts), preventing the tick from being
> incremented, as I believe happens in spnsext01.
>
> lpc-clock-config.c's lpc_clock_nanoseconds_since_last_tick(), if I'm
> understanding it correctly, says "Ah, there's an interrupt pending, so
> we need to add another tick period to our current timer value". Cool
> bananas.

Yes, this is exactly how it works.

> But what if it's called again with the same interrupt still
> pending? The timer counter may have wrapped again and we could return an
> earlier time.
>
> ...Couldn't we? What am I missing?
>
> Cheers :-)

If you disable interrupts for more than one clock tick interval, then 
you have a bigger problem than a non-monotonic uptime.

If you disable the auto-reload, then the decrementer stops, so you have 
a time freeze.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.