On Mon, 18 May 2009 18:54:49 -0400 Jeff Garzik <jgarzik@xxxxxxxxx> wrote: > 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. 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)? -- 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
