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

[Jamey Hicks]

James Bottomley wrote:

> The purpose of this API is to find a way of declaring on-chip memory as
> a pool for dma_alloc_coherent() that can be useful to all architectures.
>
> The proposed API is:
>
> nt dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
> dma_addr_t device_addr, size_t size, int flags)
>
> This API basically declares a region of memory to be handed out by
> dma_alloc_coherent when it's asked for coherent memory for this device.
>
> bus_addr is the physical address to which the memory is currently
> assigned in the bus responding region
>
> device_addr is the physical address the device needs to be programmed
> with actually to address this memory.
>
> size is the size of the area (must be multiples of PAGE_SIZE).
>
> 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.
>
> One or both of these flags must be present
>
> DMA_MEMORY_INCLUDES_CHILDREN - make the declared memory be allocated by
> dma_alloc_coherent of any child devices of this one (for memory residing
> on a bridge).
>
> DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. 
> Do not allow dma_alloc_coherent() to fall back to system memory when
> it's out of memory in the declared region.
>
> The return value would be either DMA_MEMORY_MAP or DMA_MEMORY_IO and
> must correspond to a passed in flag (i.e. no returning DMA_MEMORY_IO if
> only DMA_MEMORY_MAP were passed in) or zero for failure.
>
> I think also, it's reasonable only to have a single declared region per
> device.
>
> Implementation details
>
> Obviously, the big change is that dma_alloc_coherent() may now be
> handing out memory that can't be directly written to (in the case of a
> DMA_MEMORY_IO return).
>
> I envisage implementing an internal per device resource allocator in
> drivers/base into which each platform allocator can plug do do the heavy
> allocation lifting (they'd still get to do the platform magic to make
> the returned region visible as memory if necessary).
>
> The API would be platform optional, with platforms not wishing to
> implement it simply hard coding a return 0.
>
> There would also be a corresponding
>
> void dma_release_declared_memory(struct device *dev)
>
> whose job would be to clean up unconditionally (and not check if the
> memory were still in use).
>
> I already have this coded up on x86 and implemented for a SCSI card I
> have with four channels and a shared 2MB memory area on chip.  I'll post
> the implementations when I get it cleaned up.
>
>  
The proposed API looks like it will solve our problem.  I will work with 
Ian to test this with our drivers.

Jamey

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