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

[James Bottomley]

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.

> If I understand what you're trying to do, DMA_MEMORY_IO supports a
> new kind of DMA memory, and is necessary to work on those IBM boxes
> you were talking about ... where dma_alloc_coherent() can't work,
> and the "indirectly accessible" memory would need to be allocated
> using some new alloc/free API.  Or were you maybe trying to get at
> that "can be mmapped to userspace" distinction?

No, this IO vs MAP thing is can be mapped directly to *kernel* space.
i.e. whether the driver can use it via ordinary dereferencing or has to
use the I/O memory accessor functions.

> 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.

James

-
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/