Re: [PATCH 0/4] 34xx spurious interrupts unravelling

[David Brownell <david-b@pacbell.net>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html