summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDavid Brownell <david-b@pacbell.net>2006-04-01 10:21:52 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2006-04-14 12:25:26 -0700
commit21440d313358043b0ce5e43b00ff3c9b35a8616c (patch)
tree32f3ed659a76ad6e4a6061b57346178cf3fa6256 /include
parent2d1e1c754d641bb8a32f0ce909dcff32906830ef (diff)
downloadlinux-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