On Mon, 18 May 2009 18:54:49 -0400
Jeff Garzik [off-list ref] wrote:

Arnd Bergmann wrote:

quoted

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@arndb.de>
---
On Sunday 17 May 2009 20:05:54 Jeff Garzik wrote:

quoted

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.

Just adding one ifdef to libata.h works? What libata needs is just
wrapping dma_map_sg and dma_unmap_sg like the old ide stack does.

I'm not against the idea of an inlined version of dma-mapping-broken.h
but having two ways to handle this issue is a bit confusing; so far
what we done to handle this problem is using NO_DMA, like SCSI-ml
does, not putting the dma code in non-architecture code and having
something like scsi_lib_dma.c.

Is it theoretically correct that the dma mapping API lives in low
level drivers instead of libata-core (like how SCSI-ml does)?