lkml.org 
[lkml]   [2004]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: DMA API issues
    Matt Porter wrote:

    >On Fri, Jun 18, 2004 at 05:59:02PM +0100, Ian Molton wrote:
    >
    >
    >>I have a System On Chip device which, among other functions, contains an
    >>OHCI controller and 32K of SRAM.
    >>
    >>heres the catch:- The OHCI controller has a different address space than
    >>the host bus, and worse, can *only* DMA data from its internal SRAM.
    >>
    >>The architecture is not broken, merely unusual.
    >>
    >>This causes the following problems:
    >>
    >>1) The DMA API provides no methods to set up a mapping between the host
    >> memory map and the devices view of the space
    >> example:
    >> the OHCI controller above would see its 32K of SRAM as
    >> mapped from 0x10000 - 0x1ffff and not 0xXXX10000 - 0xXXX1ffff
    >> which is the address the CPU sees.
    >>2) The DMA API assumes the device can access SDRAM
    >> example:
    >> the OHCI controller base is mapped at 0x10000000 on my platform.
    >> this is NOT is SDRAM, its in IO space.
    >>
    >>
    >
    >Can't you just implement an arch-specific allocator for your 32KB
    >SRAM, then implement the DMA API streaming and dma_alloc/free APIs
    >on top of that? Since this architecture is obviously not designed
    >for performance, it doesn't seem to be a big deal to have the streaming
    >APIs copy to/from the kmalloced (or whatever) buffer to/from the SRAM
    >allocated memory and then have those APIs return the proper dma_addr_t
    >for the embedded OHCI's address space view of the SRAM. Same thing
    >goes for implementing dma_alloc/free (used by dma_pool*). I don't
    >have the knowledge of USB subsystem buffer usage to know how quickly
    >that little 32KB of SRAM is going to run out. But at a DMA API level,
    >this seems doable, albeit with the greater possibility of negative
    >retvals from these calls.
    >
    >
    >
    Your analysis of what is needed is correct. However, we would prefer to
    fit this into the DMA API in a generic way, rather than having a
    specialized API that is not acceptable upstream. I'm more concerned
    with finding the best way to address this problem than with whether this
    is a 2.6 or 2.7 issue.

    We do need a memory allocator for the pool of SRAM. If we're not going
    to have to build customized versions of the OHCI driver, we need that
    pool hooked into the dma_pool and dma_alloc_coherent interfaces. We
    could do that with a platform specific implementation of
    dma_alloc_coherent, but a pointer to dma_{alloc,free} from struct device
    seems like a cleaner solution. We also will need bounce buffers, as you
    described, but there is already a good start towards that support in
    2.6. The other thing that might be needed is passing device to
    page_to_dma so that device specific dma addresses can be constructed.

    Deepak Saxena wrote a pretty good summary as part if the discussion
    about this issue on the linux-arm-kernel mailing list:


    http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022796.html

    I think I'm looking for something like the PARISC hppa_dma_ops but more
    generic:

    http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2004-June/022813.html


    Jamey Hicks



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.024 / U:3.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site