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

[Jamey Hicks <jamey.hicks@hp.com>]

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