[U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Scott Wood <scottwood@freescale.com>]

On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> Hi Marek,
> 
> On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut <marex@denx.de> wrote:
> 
> > Add memory barrier to cache invalidate and flush calls.
> 
> Memory barrier...
> 
> "You keep using that word. I do not think it means what you think it
> means." :)

Could we wait on the condescension until your assertion of what a  
memory clobber does and does not do is resolved?

> A memory barrier's effect is only that all of the volatile accesses
> placed before it in the source code finish when the barrier executes,
> and that none of the volatile accesses placed after it in the source
> code starts before the barrier has executed.

Cite from official GCC documentation please, or example code that shows  
a problem.

We've use memory barriers like this all the time.  It works and is  
standard practice.  If it doesn't work like that it needs to be fixed.

That AVR/ARM example you showed on IRC is special because it's calling  
a libgcc function and GCC knows that the function doesn't access memory  
(loading constant data for the argument doesn't count).  I couldn't get  
the same thing to happen with a normal function, even when declared  
with __attribute__((const)).  Yes, it's a problem for ordering code in  
general and thus keeping slow stuff out of critical sections, but it  
shouldn't be a problem for ordering memory accesses.

-Scott