summaryrefslogtreecommitdiffstats
path: root/Documentation/DMA-mapping.txt
Commit message (Collapse)AuthorAgeFilesLines
* Documentation: remove duplicated wordsPaolo Ornati2006-10-031-1/+1
| | | | | | | | | | | | | | | Remove many duplicated words under Documentation/ and do other small cleanups. Examples: "and and" --> "and" "in in" --> "in" "the the" --> "the" "the the" --> "to the" ... Signed-off-by: Paolo Ornati <ornati@fastwebnet.it> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* Fix "can not" in Documentation and KconfigMatt LaPlante2006-10-031-1/+1
| | | | | | | | | | | Randy brought it to my attention that in proper english "can not" should always be written "cannot". I donot see any reason to argue, even if I mightnot understand why this rule exists. This patch fixes "can not" in several Documentation files as well as three Kconfigs. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [PATCH] Remove pci_dac_set_dma_mask() from Documentation/DMA-mapping.txtRolf Eike Beer2006-07-141-4/+4
| | | | | | | | | | | | pci_dac_set_dma_mask() gives only a single match in the whole kernel tree and that's in this doc file. The best candidate for replacement is pci_dac_dma_supported(). Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Cc: Greg KH <greg@kroah.com> Acked-by: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] dma doc updatesDavid Brownell2006-04-141-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* [PATCH] Last DMA_xBIT_MASK cleanupsTobias Klauser2006-04-111-2/+2
| | | | | | | | | | These are the last conversions of pci_set_dma_mask(), pci_set_consistent_dma_mask() and pci_dma_supported() to use DMA_xBIT_MASK constants from linux/dma-mapping.h Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Replace 0xff.. with correct DMA_xBIT_MASKMatthias Gehre2006-03-281-0/+2
| | | | | | | | | | Replace all occurences of 0xff.. in calls to function pci_set_dma_mask() and pci_set_consistant_dma_mask() with the corresponding DMA_xBIT_MASK from linux/dma-mapping.h. Signed-off-by: Matthias Gehre <M.Gehre@gmx.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] remove old scsi data direction macros2005-04-181-9/+3
| | | | | | | | | | these have been wrappers for the generic dma direction bits since 2.5.x. This patch converts the few remaining drivers and removes the macros. Arjan noticed there's some hunk in here that shouldn't. Updated patch below: Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+881
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
OpenPOWER on IntegriCloud