shared memory problem on ARM v5TE using threads

[Ronen Shitrit]

No TEX bits in KW.

-----Original Message-----
From: Nicolas Pitre [mailto:nico at fluxnic.net] 
Sent: Monday, December 07, 2009 5:57 PM
To: Russell King - ARM Linux
Cc: Ronen Shitrit; hs at denx.de; saeed bishara; linux-arm-kernel at lists.infradead.org
Subject: Re: shared memory problem on ARM v5TE using threads

On Mon, 7 Dec 2009, Russell King - ARM Linux wrote:

> On Mon, Dec 07, 2009 at 02:52:35PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Dec 07, 2009 at 02:55:52PM +0200, Ronen Shitrit wrote:
> > > That also match the theory:
> > > When using different processes, the shared area will stay C=1 B=1, 
> > > On each context switch L1 will be flushed,
> > > Since L2 is PIPT next process will get the correct data...
> > 
> > Hang on - if L2 is PIPT, then there shouldn't be a problem provided it's
> > searched with C=0 B=1 mappings.  Is that the case?
> 
> Officially, ARMv5 does not support the 'extended small page' format for
> the 2nd level descriptors (ARMv6 and Xscale CPUs added this support.)
> 
> That means ARMv5 officially only has support for two bits to control
> the caching attributes - the C and B bits.  This means we can't specify
> the policy for the L2 cache... unless Feroceon also supports the
> 'extended small page' format.  This might be a third solution to the
> problem, and probably the best - provided Feroceon will allow us to
> specify 'inner non-cacheable outer write-back' (TEX=111 CB=00).

Last time I checked the Feroceon doc, there was no way to have inner 
non-cacheable outer write-back behavior.  And as I mentioned in my 
previous email, while debugging the issue on an XSC3, the TEX=111 CB=00 
combination didn't appear to behave as expected (no one bothered to 
verify my findings at the time either).  So I concluded that there is no 
such thing as inner non-cacheable outer write-back on ARMv5.  This was 
consigned in commit 08e445bd6a.


Nicolas