Arnd Bergmann wrote:
h8300 and m32r currently do not provide a DMA mapping API
and therefore cannot use the ATA drivers. This adds a
generic version of dma-mapping.h for architectures that
have none or very minimal actual support for DMA in hardware
and makes the two architectures use it.
Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
---
On Sunday 17 May 2009 20:05:54 Jeff Garzik wrote:
That's what needs to happen. We provide no-op functions for e.g. PCI
and x86 DMI, for platforms where this support does not exist.
Pretty much all architectures support some form of ATA. m68k, m32r,
h8300 and microblaze all have IDE interface, which means that libata
needs to work on that platform.
The only !ATA arch in the entire kernel is s390, AFAICT.
m68k only defines NO_DMA for Sun3 and Dragonball. Sun3 does
not have ATA, Dragonball could probably just enable HAS_DMA.
---
arch/h8300/Kconfig | 2 +-
arch/h8300/include/asm/dma-mapping.h | 1 +
arch/m32r/Kconfig | 2 +-
arch/m32r/include/asm/dma-mapping.h | 1 +
include/asm-generic/dma-mapping.h | 399 ++++++++++++++++++++++++++++++++++
5 files changed, 403 insertions(+), 2 deletions(-)
create mode 100644 arch/h8300/include/asm/dma-mapping.h
create mode 100644 arch/m32r/include/asm/dma-mapping.h
create mode 100644 include/asm-generic/dma-mapping.h
My main comment is a bit non-specific... I tend to think that all
no-dma platforms should provide an API whose implementation always
returns errors, e.g. an inlined version of dma-mapping-broken.h.
That sort of setup permits the compiler's dead code elimination to work
on these no-dma platforms, while not crapping up the libata code with a
bunch of ifdefs.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
