On Thu, 2008-08-07 at 08:30 +0100, Russell King - ARM Linux wrote: > What we don't do is mark DMA memory ask being normal uncached memory, > thereby allowing that to be reordered with device accesses - we make > it strongly ordered. The reason being that the kernel doesn't have > barriers necessary to ensure that writes to DMA memory hit physical > memory before the device access to enable DMA hits the DMA controller.
We have mb() and related which provides the ordering (there is also mmiowb() but my understanding is that we don't need this on ARM). http://lwn.net/Articles/283776/ > Those kinds of bugs can be absolute hell to track down - think about > a DMA controller accessing an uninitialised DMA descriptor, resulting > in it scribbing over random bits of memory. Yes, indeed, but ARM is not the only architecture with a weak memory ordering model so drivers should be fixed, in theory. > Linux presently - and quite rightly - assumes that accesses to DMA > coherent memory _are_ coherent with DMA. If not, the API would be > a joke. As I understand it, the DMA mapping doesn't guarantee any ordering, drivers must use barriers. According to Documentation/DMA-mapping.txt: - Consistent DMA mappings which are usually mapped at driver initialization, unmapped at the end and for which the hardware should guarantee that the device and the CPU can access the data in parallel and will see updates made by each other without any explicit software flushing. [...] IMPORTANT: Consistent DMA memory does not preclude the usage of proper memory barriers. The CPU may reorder stores to consistent memory just as it may normal memory. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
