On Friday 23 December 2011, Marek Szyprowski wrote:
The solution we found is to introduce a new public dma mapping functions
with additional attributes argument: dma_alloc_attrs and
dma_free_attrs(). This way all different kinds of architecture specific
buffer mappings can be hidden behind the
Hello,
To help everyone in testing and adapting our patches for his hardware
platform I've rebased our patches onto the latest v3.2 Linux kernel and
prepared a few GIT branches in our public repository. These branches
contain our memory management related patches posted in the following
threads:
Hello,
On Tuesday, December 27, 2011 6:53 PM James Bottomley wrote:
On Tue, 2011-12-27 at 09:25 +0100, Marek Szyprowski wrote:
[...]
Usually these drivers don't touch the buffer data at all, so the mapping
in kernel virtual address space is not needed. We can introduce
Hello,
On Friday, December 23, 2011 5:35 PM Matthew Wilcox wrote:
On Fri, Dec 23, 2011 at 01:27:19PM +0100, Marek Szyprowski wrote:
The first issue we identified is the fact that on some platform (again,
mainly ARM) there are several functions for allocating DMA buffers:
On Fri, Dec 23, 2011 at 01:27:19PM +0100, Marek Szyprowski wrote:
The first issue we identified is the fact that on some platform (again,
mainly ARM) there are several functions for allocating DMA buffers:
dma_alloc_coherent, dma_alloc_writecombine and dma_alloc_noncoherent
Is this
On Fri, 2011-12-23 at 09:35 -0700, Matthew Wilcox wrote:
I really think this wants to be a separate function.
dma_alloc_coherent
is for allocating memory to be shared between the kernel and a driver;
we already have dma_map_sg for mapping userspace I/O as an alternative
interface. This feels
