aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-arm/dma-mapping.h
Commit message (Collapse)AuthorAge
*-. Merge AT91, EP93xx, General devel, PXA, S3C, V6+ and Xscale treesRussell King2007-02-17
|\ \
| | * [ARM] Convert DMA cache handling to take const void * argsRussell King2007-02-08
| |/ | | | | | | | | | | | | | | | | The DMA cache handling functions take virtual addresses, but in the form of unsigned long arguments. This leads to a little confusion about what exactly they take. So, convert them to take const void * instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* / [ARM] Provide dummy noncoherent DMA APIRussell King2007-02-12
|/ | | | | | | We don't currently support the noncoherent DMA API, but it needs to be provided for kernels with devres to link. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] Add struct dev pointer to dma_is_consistent()Ralf Baechle2006-12-07
| | | | | | | | | | | | | | | dma_is_consistent() is ill-designed in that it does not have a struct device pointer argument which makes proper support for systems that consist of a mix of coherent and non-coherent DMA devices hard. Change dma_is_consistent to take a struct device pointer as first argument and fix the sole caller to pass it. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [ARM] 3942/1: ARM: comment: consistent_sync should not be called directlyDan Williams2006-11-22
| | | | | | | | | | | /* * Note: Drivers should NOT use this function directly, as it will break * platforms with CONFIG_DMABOUNCE. * Use the driver DMA support - see dma-mapping.h (dma_sync_*) */ Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [ARM] 3439/2: xsc3: add I/O coherency supportLennert Buytenhek2006-04-01
| | | | | | | | | | | | | | | | | | | | | Patch from Lennert Buytenhek This patch adds support for the I/O coherent cache available on the xsc3. The approach is to provide a simple API to determine whether the chipset supports coherency by calling arch_is_coherent() and then setting the appropriate system memory PTE and PMD bits. In addition, we call this API on dma_alloc_coherent() and dma_map_single() calls. A generic version exists that will compile out all the coherency-related code that is not needed on the majority of ARM systems. Note that we do not check for coherency in the dma_alloc_writecombine() function as that still requires a special PTE setting. We also don't touch dma_mmap_coherent() as that is a special ARM-only API that is by definition only used on non-coherent system. Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [PATCH] gfp_t: dma-mapping (arm)Al Viro2005-10-28
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] arm: add comment about dma_supported()akpm@osdl.org2005-04-16
| | | | | | | | | | | | | | | ) From: Russell King <rmk+lkml@arm.linux.org.uk> The ARM dma_supported() is rather basic, and I don't think it takes into account everything that it should do (eg, whether the mask agrees with what we'd return for GFP_DMA allocations). Note this. Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!