Messages in this thread | | | Date | Thu, 01 Jul 2004 08:43:07 -0400 | From | Jamey Hicks <> | Subject | Re: [RFC] on-chip coherent memory API for DMA |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |