On Tue, 2007-08-21 at 17:34 -0700, [EMAIL PROTECTED] wrote: > On Tue, Aug 21, 2007 at 03:55:29PM -0500, James Bottomley wrote: > > > ..... > > Almost every platform supports posted DMA ... its a property of most PCI > > bridge chips. > > > > The term "posted DMA" is used to describe this behavior in the Altix > Device Driver Writer's Guide, but it may be confusing things here. > Maybe a better term will suggest itself if I can clarify....
OK, but posted DMA has a pretty specific meaning in terms of PCI, hence the confusion. > On Altix, DMA from a device isn't guaranteed to arrive in host memory > in the order it was sent from the device. This reordering can happen > in the NUMA interconnect (it's specifically not a PCI reordering.) This is mmiowb and read_relaxed() again, isn't it? > > ...... > > This isn't possible on most platforms. PCI write posting can only be > > flushed by a read transaction on the device (or sometimes any device on > > the bridge). Either this interface is misnamed and misdescribed, or it > > can't work for most systems. > > > > Clearly it wasn't described adequately... > > A read transaction on the device will flush pending writes to the > device. But I'm worried about DMA from the device to host memory. > On Altix, there are two mechanisms that flush all in-flight DMA > to host memory: 1) an interrupt, and 2) a write to a memory region > which has a "barrier" attribute set. Obviously option 1 isn't > viable for performance reasons. This new interface is about making > "option 2" generally available. (As it is now, the only way to get > memory with the "barrier" attribute is to allocate it with > dma_alloc_coherent().) Which sounds exactly what mmiowb does ... is there a need for a new API; can't you just use mmiowb()? James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
