Re: [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2007-08-21 at 17:34 -0700, akepner@sgi.com 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/