[RFC 06/18] arm: msm: implement proper dmb() for 7x27

Russell King - ARM Linux linux at arm.linux.org.uk
Tue Jan 19 18:11:11 EST 2010


On Tue, Jan 19, 2010 at 09:12:44PM +0000, Jamie Lokier wrote:
> Fair enough.  Is it like this?
> 
>    1. Data ends up in cache lines from access via the cached mapping.
>    2. Access via the strongly ordered mapping may still look at the cache,
>       because it's easier that way and it's not supposed to have any data.
>    3. Cache effectively intercepts the access.
>    4. Bus does not see strongly ordered access.

Yes, that's one possible scenario.

> Isn't the above sequence of events you described earlier even _more_
> likely to occur when there are simultaneous cacheable and
> non-cacheable mappings?

I guess it depends how the access hardware is designed - and what
effect an access resulting in a device or strongly ordered type access
(thereby having one set of ordering requirements) has when it hits a
cache line, which will have different ordering requirements.

With ARMv6 and above, it's no longer just about cache policy, as with
previous CPUs.  There's ordering requirements to ensure that (eg) device
accesses occur on the busses in program order rather than out of order,
and this will require hardware - which could be confused by a device
access hitting the cache.

The difference between this and differing cache policies, the ordering
requirement is the same.

(ISTR ARM Ltd's architecture folk know about the problem Linux has with
cache policies, and although this requirement is written into the arch
manual, they're aware that Linux will have major problems with it.  I
believe the only unpredictability that results from this that a NC
region may end up with cache lines allocated, which may or may not be
hit.  That's not to say that it _won't_ become a problem with later
ARM CPUs, but let's pray that when it does, we have coherent DMA
support.)



More information about the linux-arm-kernel mailing list