Messages in this thread | | | Subject | Re: [PATCH v2] sata_sil24: Use memory barriers before issuing commands | From | Catalin Marinas <> | Date | Thu, 10 Jun 2010 17:42:48 +0100 |
| |
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@arm.com> > > > Tested-by: Colin Tuckley <colin.tuckley@arm.com> > > > Cc: Tejun Heo <tj@kernel.org> > > > Cc: Jeff Garzik <jeff@garzik.org> > > > > 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
| |