Messages in this thread | | | Date | Mon, 08 Feb 2010 11:17:34 -0800 | From | Abhijeet Dharmapurikar <> | Subject | Re: [RFC PATCH] ARM: Change the mandatory barriers implementation |
| |
Catalin Marinas wrote: > On Thu, 2010-02-04 at 13:15 +0000, Catalin Marinas wrote: >> On Thu, 2010-02-04 at 00:21 +0000, Abhijeet Dharmapurikar wrote: >>>> The mandatory barriers (mb, rmb, wmb) are used even on uniprocessor >>>> systems for things like ordering Normal Non-cacheable memory accesses >>>> with DMA transfer (via Device memory writes). The current implementation >>>> uses dmb() for mb() and friends but this is not sufficient. The DMB only >>>> ensures the ordering of accesses with regards to a single observer >>>> accessing the same memory. If a DMA transfer is started by a write to >>>> Device memory, the data to be transfered may not reach the main memory >>>> (even if mapped as Normal Non-cacheable) before the device receives the >>>> notification to begin the transfer. The only barrier that would help in >>>> this situation is DSB which would completely drain the write buffers. >>> On ARMv7, DMB guarantees that all accesses prior to DMB are observed by >>> an observer if that observer sees any accesses _after_ the DMB. In this >>> case, since DMA engine observes a write to itself( It is being written >>> to and hence must observe the write) it should also see the writes to >>> the buffers. A dmb() after the writes to buffer and before write to DMA >>> engine should suffice. >> I asked our processor architect for a clarification on the wording of >> the DMB definition but the "all accesses" part most likely refer to >> accesses to the same peripheral or memory block (but not together). > > I got some clarification and there is nothing wrong with the definition > of the DMB. The catch here is that "observe" (as per the ARM ARM) is > defined only for master accesses. The DMA engine in this case above does > not "observe" the write to itself as this is a slave access to one of > its memory-mapped ports. > > So, the code below: > > STR [Normal non-cacheable] > DMB > STR [Device] > > puts the first store in Group A (according to the DMB definition) and > the second store in Group B but since the DMA device does not "observe" > Group B in this case, there is no requirement for the ordering between > the observability of the store to normal memory and the observability of > the side-effects of the store to the DMA device.
I agree now. DSB would be the right thing to do. Moreover the option to have a barrier.h for each platform gives them a chance to fine tune these barriers further.
| |