lkml.org 
[lkml]   [2004]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] on-chip coherent memory API for DMA
James Bottomley wrote:
> On Thu, 2004-07-01 at 09:12, David Brownell wrote:
>
>>The API looked OK except this part didn't make sense to me, since
>>as I understand things dma_alloc_coherent() is guaranteed to have
>>the DMA_MEMORY_MAP semantics at all times ... the CPU virtual address
>>returned may always be directly written. That's certainly how all
>>the code I've seen using dma_alloc_coherent() works.
>
>
>>It'd make more sense if the routine were "dma_declare_memory()", and
>>DMA_MEMORY_MAP meant it was OK to return from dma_alloc_coherent(),
>>while DMA_MEMORY_IO meant the dma_alloc_coherent() would always fail.
>
>
> You need an allocator paired with IO memory. If the driver allows for
> DMA_MEMORY_IO then it's not unreasonable to expect it to have such
> memory returned by dma_alloc_coherent() rather than adding yet another
> allocator API.

Seems unreasonable to me, unless there's also an API to change
the mode of the dma_alloc_coherent() memory from the normal
"CPU can read/write as usual" to the exotic "need to use special
memory accessors". (And another to report what mode the API is
in at the current moment.)

And I don't like modal APIs like that, which is why it'd make
more sense to me to have a new allocator API for this new
kind of DMA memory. (Which IS for that IBM processor, yes?)

Alternatively, modify dma_alloc_coherent() to say what kind
of address it must return. Since this is a "generic" DMA
API, the caller of dma_alloc_coherent() shouldn't need to be
guessing how they may actually use the memory returned.
That new "must guess" requirement will break some code...


>>Also in terms of implementation, I noticed that if there's a
>>dev->dma_mem, the GFP_* flags are ignored. For __GFP_NOFAIL
>>that seems buglike, but not critical. (Just looked at x86.)
>>Might be worth just passing the flags down so that behavior
>>can be upgraded later.
>
>
> Actually, there's no point respecting the flags for the on chip region.
> Either the memory is there or it isn't. If it isn't there, then you
> either fall through to the ordinary allocator (where the flags are
> respected) or fail if the DMA_MEMORY_EXCLUSIVE flag was specified.

So -- you're saying it's not a bug that a __GFP_NOFAIL|__GFP_WAIT
allocation be able to fail? Curious. I'd have thought the API
was clear about that. Allocating 128 MB from a 1 MB region must
of course fail, but allocating one page just needs a wait/wakeup.

- Dave


-
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:04    [W:0.054 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site