On Thu, 2010-06-10 at 17:23 +0100, Catalin Marinas wrote: > On Thu, 2010-06-10 at 17:12 +0100, Tejun Heo wrote: > > On 06/10/2010 06:02 PM, Catalin Marinas wrote: > > > The data in the cmd_block buffers may reach the main memory after the > > > writel() to the device ports. This patch introduces two calls to wmb() > > > to ensure the relative ordering. > > > > > > Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx> > > > Tested-by: Colin Tuckley <colin.tuckley@xxxxxxx> > > > Cc: Tejun Heo <tj@xxxxxxxxxx> > > > Cc: Jeff Garzik <jeff@xxxxxxxxxx> > > > > I suppose you have tested and verified that this is actually > > necessary, right? > > Yes, otherwise we get random failures with this device on ARM. > > > I've been looking through the docs but couldn't > > find anything which described the ordering between writes to main > > memory and write[bwl]()'s. One thing that kind of bothers me is that > > r/wmb()'s are for ordering memory accesses among CPUs which > > participate in cache coherency protocol and although it may work right > > in the above case I'm not really sure whether this is the right thing > > to do. Do you have more information on the subject? > > The mb() are not for ordering accesses among CPUs (though they would > cover this case as well). For inter-CPU ordering, we have smp_mb() and > friends. For all other cases, we have the mandatory barriers mb() and > friends and DMA is one of them. > > Apart from the memory-barriers.txt document, there is the Device I/O > docbook which mentions something about DMA buffers, though not very > clear on which barriers to use (something like just make sure that the > writes to the buffer reached the memory). It was actually the DMA-API.txt (rather than deviceiobook) in the description of dma_alloc_coherent(). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
