[PATCH] Correct a race condition between the e500 core decrementer wrapping and the tick interrupt being handled
Nick Withers
nick.withers at anu.edu.au
Wed Dec 10 01:53:28 UTC 2014
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. 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 :-)
--
Nick Withers
Embedded Systems Programmer
Department of Nuclear Physics, Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)
More information about the devel
mailing list