2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-28 07:04:00 +08:00
Commit Graph

8 Commits

Author SHA1 Message Date
Jens Axboe
9b6eccfccb IA64: sg chaining support
This updates the ia64 iommu/pci dma mappers to sg chaining.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-10-16 11:27:26 +02:00
Tony Luck
0df333ce01 [IA64] build fix for scatterlist
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>
2007-10-15 13:49:43 -07:00
Roland Dreier
b7de8e7e3c [PATCH] ia64: fix noncoherent DMA API so devres builds
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>
2007-02-14 08:09:51 -08:00
Ralf Baechle
d3fa72e455 [PATCH] Pass struct dev pointer to dma_cache_sync()
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>
2006-12-07 08:39:41 -08:00
Ralf Baechle
f67637ee4b [PATCH] Add struct dev pointer to dma_is_consistent()
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>
2006-12-07 08:39:41 -08:00
David Woodhouse
62c4f0a2d5 Don't include linux/config.h from anywhere else in include/
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
2006-04-26 12:56:16 +01:00
John W. Linville
e1531b4218 [PATCH] ia64: re-implement dma_get_cache_alignment to avoid EXPORT_SYMBOL
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>
2005-11-07 07:53:23 -08:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00