These statements appear not even remotely valid. Certainly the CPU is only a bus master, so when you say slave/master memory access, what are you referring to?<br><br>(Sorry for accidentally bringing the thread off the list for the last 2 posts. Bringing it back.)<br>
<br>Best Regards,<br>Martin Furmanski<br><br><div class="gmail_quote">On Tue, Mar 29, 2011 at 6:37 PM, Catalin Marinas <span dir="ltr"><<a href="mailto:catalin.marinas@arm.com">catalin.marinas@arm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">On Tue, 2011-03-29 at 17:16 +0100, Martin Furmanski wrote:<br>
> From memory_barriers.txt, regarding rmb():<br>
><br>
> " (3) Read (or load) memory barriers.<br>
><br>
> A read barrier is a data dependency barrier plus a guarantee that all the<br>
> LOAD operations specified before the barrier will appear to happen before<br>
> all the LOAD operations specified after the barrier with respect to the<br>
> other components of the system."<br>
><br>
> If above is the semantics that you are aiming for, then it is still irrelevant whether<br>
> the memory is Normal or Device. But other than that, I see no issues.<br>
<br>
</div>The relevant part is that a Device access is usually a *slave* access<br>
while Normal memory access is a *master* one. The DMB only ensures the<br>
latter (as specified by the ARM ARM, though probably not very clear).<br>
<br>
I'm not sure whether the memory-barriers.txt doc covers all the usage in<br>
the kernel but the mandatory barriers (mb/rmb/wmb) may be used to<br>
control the effect of I/O accesses (as per the above document). On ARM,<br>
this needs to be DSB rather than DMB.<br>
<br>
I can even give examples where a DMB would fail with regards to Device<br>
memory.<br>
<br>
--<br>
<font color="#888888">Catalin<br>
<br>
<br>
</font></blockquote></div><br>