* David Brownell <david-b@xxxxxxxxxxx> [081031 13:07]: > On Friday 31 October 2008, Tony Lindgren wrote: > > So it's now starting to look like we need to ensure write posting in > > interrupt handlers for 34xx instead of marking the IO areas as strongly > > ordered. > > I always thought the terminology was to "flush posted writes" > by the readback ... a "posted write" being one that's sitting > in a hardware queue, like a letter sitting in a mailbox until > the postal service picks it up (then, much later, delivers it). That sounds more professional. Let's standardize the comments to say "flush posted write" so we can easily grep for them later on. > Regardless, these patches just go to show that OMAP hardware > is starting to act more like bigger hardware ... like stuff > with PCI busses, where writes are normally posted to bridge > writebuffers and drivers need to defend against the relevant > write latencies. :) > > > One thing for folk to remember: the consequent races happen > outside of IRQ handling too. > > Every time you write to an I/O register you should ask when > its effect *must* be known to the hardware ... and ensure some > read flushes that write before that deadline. When you get it > wrong, be prepared to waste time tracking down intermittent > race induced failures at very low levels. > > When in doubt, flush it out! > > > 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(). Tony -- 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
