[PATCH 3/4] dma: document dma_flags_set_dmaflush()

[akepner]

Document dma_flags_set_dmaflush().

Signed-off-by: Arthur Kepner <akepner@xxxxxxx>
--
 DMA-mapping.txt |   25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt
index e07f253..31e3234 100644
--- a/Documentation/DMA-mapping.txt
+++ b/Documentation/DMA-mapping.txt
@@ -745,7 +745,30 @@ to "Closing".
    2.5., page+offset is always used, and the "address" field has been
    deleted.
 
-2) More to come...
+2) Platforms that permit DMA reordering
+
+   At least one platform (SGI SN2) allows DMA to be reordered between
+   device and host memory. This reordering can happen in the NUMA
+   interconnect, and it usually results in correct operation and improved
+   performance. In some situations it may be necessary to explicitly
+   synchronize DMA from the device. For example, if the device does a DMA
+   write to indicate that data is ready, the DMA of the "completion
+   indication" can race with DMA of data. In this situation,
+   dma_flags_set_dmaflush() can be used to associate a "dmaflush"
+   attribute with a memory region. The dmaflush attribute will cause in-
+   flight DMA from the device to be flushed to host memory when the
+   associated memory region is written. (On platforms that don't permit
+   DMA reordering, this is a no-op.)
+
+   For example, you might map the memory region used for completion
+   indications as follows:
+
+	int count, flags = dma_flags_set_dmaflush(DMA_BIDIRECTIONAL);
+	.....
+	count = dma_map_sg(dev, sglist, nents, flags);
+
+
+3) More to come...
 
 			Handling Errors
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/