aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-ia64/dma-mapping.h
Commit message (Collapse)AuthorAge
* IA64: sg chaining supportJens Axboe2007-10-16
| | | | | | This updates the ia64 iommu/pci dma mappers to sg chaining. Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
* [IA64] build fix for scatterlistTony Luck2007-10-15
| | | | | | | | | include/scsi/scsi_eh.h:79: error: field `sense_sgl' has incomplete type x86 resolves this by including scatterlist.h from dma-mapping.h which seems as good a place as any. Signed-off-by: Tony Luck <tony.luck@intel.com>
* [PATCH] ia64: fix noncoherent DMA API so devres buildsRoland Dreier2007-02-14
| | | | | | | | | | | | | | | | | | | | | | | | On ia64, drivers/base/dma-mapping.c doesn't build because it calls dma_alloc_noncoherent() and dma_free_noncoherent(), which appear to be terminally broken; the calls end up generating errors like drivers/base/dma-mapping.c: In function 'dmam_noncoherent_release': drivers/base/dma-mapping.c:32: error: 'struct ia64_machine_vector' has no member named 'platform_dma_free_coherent' because the multiple levels of macro expansion in <asm/dma-mapping.h> and <asm/machvec.h> end up turning a call to dma_free_noncoherent() into ia64_mv.platform_dma_free_coherent (instead of the intended ia64_mv.dma_free_coherent). This patch fixes this by converting dma_{alloc,free}_noncoherent() into inline functions that call the corresponding coherent functions, instead of trying to do this with macros. Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Tony Luck <tony.luck@intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] Pass struct dev pointer to dma_cache_sync()Ralf Baechle2006-12-07
| | | | | | | | | | | | | | | | | Pass struct dev pointer to dma_cache_sync() dma_cache_sync() 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_cache_sync to take a struct device pointer as first argument and fix all its callers 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>
* [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>
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOLJohn W. Linville2005-11-07
| | | | | | | | | | | | | The current ia64 implementation of dma_get_cache_alignment does not work for modules because it relies on a symbol which is not exported. Direct access to a global is a little ugly anyway, so this patch re-implements dma_get_cache_alignment in a manner similar to what is currently used for x86_64. Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: "Luck, Tony" <tony.luck@intel.com> 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!