Re: [RFC] on-chip coherent memory API for DMA

[David Brownell <david-b@pacbell.net>]

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