[lkml]   [2004]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DMA API issues
    On Sat, Jun 19, 2004 at 11:23:23AM -0700, David Brownell wrote:
    > I'm having to guess at your point here, even from other emails.
    > You've asserted a difference, but not what it is. Maybe it's
    > something to do with the problem's NUMA nature? Are you for
    > some reason applying DMA _mapping_ requirements (main-memory
    > only) to the DMA memory _allocation_ problem?

    I suspect the problem is concerning how Linux backs the memory and
    what is assumed to be backing memory returned from the DMA coherent

    Currently, there are drivers which assume that it's possible that
    dma_alloc_coherent memory is backed by system memory, which has
    page structures associated with each page. For this "new" memory,
    there are no such page structures, so things like bus_to_virt()
    don't work on them (not that they were guaranteed to work on a
    dma_addr_t _anyway_ but that doesn't stop driver authors thinking
    that they do work - and as code presently stands, they do indeed

    In addition, the ARM implementation of dma_alloc_coherent()
    implicitly believes in struct page pointers - they're a fundamental
    properly of the way that has been implemented, so any deviation from
    "memory with struct page" means more or less a rewrite this.

    I would say that, yes, from a perfectly objective view, if you are
    unable to do coherent DMA from system memory, but your system provides
    you with a totally separate memory system which does indeed provide
    coherent DMA, it seems logical to allow dma_alloc_coherent() to use
    it - at risk of breaking some drivers making incorrect assumptions.

    And I don't see _that_ case as being vastly different from Ian's

    So, I think as long as we can ensure that drivers do not make bad
    assumptions about dma_alloc_coherent() _and_ we have a suitable DMA
    MMAP API to solve the cases where device drivers want to mmap DMA
    buffers (and they _do_ want to do this) it should be possible.

    Depending on how I look at the problem, I'm oscillating between "yes
    it should be done" (if its an overall system thing like DMA memory
    on a PCI north bridge separate from your normal system non-DMA
    memory) and "no it's out of the question."

    > Well, no other memory in the entire system meets the requirements
    > for the dma_alloc_coherent() API, since _only that_ chunk of memory
    > is works with that device's DMA hardware. Which is the fundamental
    > problem that needs to be solved. It can clearly done at the platform
    > level, using device- or bus-specific implementations.

    The counter-argument here is to consider the case of video cards.
    They do almost continuous DMA from on-board RAM, yet the DMA API
    doesn't get involved...

    So I'm afraid I'm sitting on the fence between the two sides not
    really knowing which side to fall off to. It sounds to me like
    other people here are in a similar situation.

    Russell King
    Linux kernel 2.6 ARM Linux -
    maintainer of: 2.6 PCMCIA -
    2.6 Serial core
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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