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

[David Brownell]

James Bottomley wrote:
> dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
> dma_addr_t device_addr, size_t size, int flags)
>
> ...
>
> The flags is where all the magic is.  They can be or'd together and are
>
> DMA_MEMORY_MAP - request that the memory returned from
> dma_alloc_coherent() be directly writeable.
>
> DMA_MEMORY_IO - request that the memory returned from
> dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.

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.

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?


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.

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