Hi Marek,
First, a (long) preamble with some general considerations:
A. This patch does not fix an actual issues; it is a prospective patch,
modifying code which so far has not malfunctioned, or at least has not
been reported to malfunction.
B. My comments on the patch below are based on the gen
On 10/11/2012 06:37:40 PM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 15:21:28 -0500, Scott Wood
wrote:
> > http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm
> >
> > "If your assembler instructions access memory in an unpredictable
> > fashion, add `memory' to the list
Hi Scott,
On Thu, 11 Oct 2012 15:21:28 -0500, Scott Wood
wrote:
> > Scott, I think you should not mistake as condescension what is just
> > humo(u)r. What I wrote above is a quotation from a (light, quite
> > humorous and above all, self-mocking) movie, meant to be read by, but
> > in
> > no w
Hi Scott,
On Thu, 11 Oct 2012 16:09:28 -0500, Scott Wood
wrote:
> On 10/11/2012 03:01:32 PM, Albert ARIBAUD wrote:
> > Hi Mark,
> >
> > Thanks for your example.
> >
> > > My understanding of gcc is that global memory accesses are meant to
> > > stay on the correct side of an asm with a "memory
On 10/11/2012 03:01:32 PM, Albert ARIBAUD wrote:
Hi Mark,
Thanks for your example.
> My understanding of gcc is that global memory accesses are meant to
> stay on the correct side of an asm with a "memory" clobber. The gcc
> manual states that if you use a memory clobber, the asm should also
>
On 10/11/2012 03:03:29 PM, Albert ARIBAUD wrote:
Hi Scott,
On Thu, 11 Oct 2012 13:03:13 -0500, Scott Wood
wrote:
> On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> > Hi Marek,
> >
> > On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut
wrote:
> >
> > > Add memory barrier to cache invalidate
Hi Scott,
On Thu, 11 Oct 2012 13:03:13 -0500, Scott Wood
wrote:
> On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> > Hi Marek,
> >
> > On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut wrote:
> >
> > > Add memory barrier to cache invalidate and flush calls.
> >
> > Memory barrier...
> >
> >
Hi Mark,
Thanks for your example.
> My understanding of gcc is that global memory accesses are meant to
> stay on the correct side of an asm with a "memory" clobber. The gcc
> manual states that if you use a memory clobber, the asm should also
> be volatile.
Not exactly. It states that you n
On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
Hi Marek,
On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut 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
Dear Albert ARIBAUD,
> Hi Marek,
>
> On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut 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
Hi Marek,
On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut 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
plac
Add memory barrier to cache invalidate and flush calls.
Signed-off-by: Marek Vasut
CC: Albert Aribaud
Cc: Fabio Estevam
Cc: Otavio Salvador
Cc: Stefano Babic
---
arch/arm/cpu/arm926ejs/cache.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/arm92
Add memory barrier to cache invalidate and flush calls. This prevents
compiler from reordering the code around these, possibly generating
invalid results.
Signed-off-by: Marek Vasut
CC: Albert Aribaud
Cc: Fabio Estevam
Cc: Otavio Salvador
Cc: Stefano Babic
---
arch/arm/cpu/arm926ejs/cache.c
13 matches
Mail list logo
