From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Thu, 11 Oct 2012 14:09:44 +0200
Subject: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush
In-Reply-To: <20121011073146.43ba7000@lilith>
References: <1349822669-26274-1-git-send-email-marex@denx.de>
	<20121011073146.43ba7000@lilith>
Message-ID: <201210111409.44756.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Albert ARIBAUD,

> 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." :)
> 
> 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.
> 
> Non-volatile accesses are not guaranteed to stay on one side of the
> barrier, and the barrier itself is not guaranteed to stay put during
> optimizations.
> 
> If what you intended was to ensure that e.g. all writes be finished
> when a flush occurs

Yes, that's pretty much it. To ensure that all writes to the flushed memory area 
are finished before the flushing happens.

> or that no read happens before an invalide has
> executed, then adding memory clobbers is not an adequate solution.

What do you suggest?

> If you were aiming for something else entirely, please don't hesitate
> to develop a description of the problem you wish to solve.
> 
> Amicalement,

Best regards,
Marek Vasut