lkml.org 
[lkml]   [2004]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.065 / U:2.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site