diff options
author | David Brownell <david-b@pacbell.net> | 2006-04-01 10:21:52 -0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@suse.de> | 2006-04-14 12:25:26 -0700 |
commit | 21440d313358043b0ce5e43b00ff3c9b35a8616c (patch) | |
tree | 32f3ed659a76ad6e4a6061b57346178cf3fa6256 /include | |
parent | 2d1e1c754d641bb8a32f0ce909dcff32906830ef (diff) | |
download | linux-3.10-21440d313358043b0ce5e43b00ff3c9b35a8616c.tar.gz linux-3.10-21440d313358043b0ce5e43b00ff3c9b35a8616c.tar.bz2 linux-3.10-21440d313358043b0ce5e43b00ff3c9b35a8616c.zip |
[PATCH] dma doc updates
This updates the DMA API documentation to address a few issues:
- The dma_map_sg() call results are used like pci_map_sg() results:
using sg_dma_address() and sg_dma_len(). That's not wholly obvious
to folk reading _only_ the "new" DMA-API.txt writeup.
- Buffers allocated by dma_alloc_coherent() may not be completely
free of coherency concerns ... some CPUs also have write buffers
that may need to be flushed.
- Cacheline coherence issues are now mentioned as being among issues
which affect dma buffers, and complicate/prevent using of static and
(especially) stack based buffers with the DMA calls.
I don't think many drivers currently need to worry about flushing write
buffers, but I did hit it with one SOC using external SDRAM for DMA
descriptors: without explicit writebuffer flushing, the on-chip DMA
controller accessed descriptors before the CPU completed the writes.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions