[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070822003450.GM5592@sgi.com>
Date: Tue, 21 Aug 2007 17:34:50 -0700
From: akepner@....com
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Randy Dunlap <randy.dunlap@...cle.com>, Jes Sorensen <jes@....com>,
linux-kernel <linux-kernel@...r.kernel.org>, rdreier@...co.com,
linux-ia64 <linux-ia64@...r.kernel.org>
Subject: Re: [PATCH 2/3] dma: override "dma_flags_set_dmaflush" for sn-ia64
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....
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 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().)
--
Arthur
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists