On Friday 31 October 2008, Tony Lindgren wrote: > > > For PIO drivers, IRQ handling is the main place these races > > will appear. If DMA is in use, there are a boatload of > > additional complications that can crop up ... sometimes you > > need to worry about when writes get to memory (DMA mapping > > ops don't necessarily ensure the CPU write buffer is empty), > > and unless the peripheral has an integrated DMA engine you > > need to flush writes to the DMA engine separately from > > writes to the peripheral. > > Yeah, especially when recycling dma buffers.. The call to use > there is dma_cache_maint(). Well, not directly ... call dma_map_*() and dma_sync_*(), letting those functions call dma_cache_maint() as needed. (See arch/arm/include/asm/dma-mapping.h ...) That said, I have seen platforms where the fact that those calls can leave data in the CPU write buffer made trouble. As in, issue those dma cache updates, then write to the DMA or peripheral controller registers ... and the key data was still in the write buffers when those writes completed! That's quite unusual; possibly related to memory controller bugs in that silicon revision. (And there are converse problems in drivers that collect status from both DMA buffers/descriptors and from peripheral registers. Status can show up in registers before memory because of buffering on those paths, and vice versa. The varying clock rates matter ... maybe the memory writes are synced to a 166 MHz clock, but the peripheral internally uses a 48 MHz clock domain.) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
