lkml.org 
[lkml]   [2009]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] asm-generic: add a dma-mapping.h file
    From
    On Mon, 18 May 2009 18:54:49 -0400
    Jeff Garzik <jgarzik@pobox.com> 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@arndb.de>
    > > ---
    > > 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)?


    \
     
     \ /
      Last update: 2009-05-19 01:27    [W:0.025 / U:1.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site