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

[David Brownell]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/