[GSOC] RPi BSP memory barrier

[Andre Marques]

Hello,

I have updated the blog [1]  last week with some info on memory barriers 
for the ARM achitecture.

As for the RPi BSP, the needed inline assembly may be implemented in 
three ways:

1. Any explicit memory access is done through a function, which wraps 
the memory access instruction with memory barrier calls (as the rpi-boot 
code does [2]).

Garantees that all memory accesses are protected, but doubles the needed 
calls. For instance, if I want to read two times:

call memory_barrier
read
call memory_barrier
call memory_barrier
read
call memory_barrier

The only advantage I see with this approach is that if the next memory 
access does not call memory_barrier, it would be protected. But then if 
the next does not call it either, the advantage is gone.

The point is that all memory access instructions must call 
memory_barrier before. Calling memory_barrier after the memory access 
leads to unnecessary memory_barrier calls.

2. The same as 1., but calling memory_barrier only before the memory 
access instruction.

3. A new macro would be created with the inline assembly, and the memory 
barrier is called when appropriate. The driver developer would call 
memory_barrier when seen fit. This may lead to some hard to find bugs.

Any thoughts on this?

--André Marques

[1] - http://asuolgsoc2014.wordpress.com/2014/04/27/memory-barrier/
[2] - https://github.com/jncronin/rpi-boot/blob/master/mmio.c