Thread (8 messages) flat view 8 messages, 4 authors, 2012-07-23

[PATCH][RFC] arm: dma-mapping: Add support for allocating/mapping cached buffers

From: m.szyprowski@samsung.com (Marek Szyprowski)
Date: 2012-07-23 07:22:24
Also in: linux-arm-msm


-----Original Message-----
From: Laura Abbott [mailto:lauraa at codeaurora.org]
Sent: Friday, July 20, 2012 10:30 PM
To: Marek Szyprowski
Cc: linaro-mm-sig at lists.linaro.org; 'Russell King'; linux-arm-msm at vger.kernel.org; linux-arm-
kernel at lists.infradead.org
Subject: Re: [PATCH][RFC] arm: dma-mapping: Add support for allocating/mapping cached buffers

On 7/16/2012 10:58 PM, Marek Szyprowski wrote:
quoted
Hi Laura,

On Friday, July 13, 2012 8:02 PM Laura Abbott wrote:
quoted
There are currently no dma allocation APIs that support cached
buffers. For some use cases, caching provides a signficiant
performance boost that beats write-combining regions. Add
apis to allocate and map a cached DMA region.

Signed-off-by: Laura Abbott <redacted>
I agree that there is a need for cached contiguous memory blocks. I see that your patch
is based on some older version of CMA/dma-mapping code. In v3.5-rc1 CMA has been merged
to mainline kernel together with DMA-mapping redesign patches, so an attribute approach
can be used instead of adding new functions to the API. My original idea was to utilize
the dma_alloc_nonconsistent() call and DMA_ATTR_NONCONSISTENT for allocating/mapping
cached contiguous buffers, but I didn't have enough time for completing this work.

The main missing piece is the API for managing cache synchronization on such buffers.
There is a dma_cache_synch() functions but it is broken from the API point of view. To
replace it with something better, some additional work is needed for all drivers which
already use it. Also some work in needed for cleanup dma_alloc_nonconsistent()
implementations for all the architectures using dma_map_ops approach. All this is on my
TODO list, but I currently I'm really busy with other tasks related to CMA (mainly
bugfixes for some special use-cases).
In what is the dma_cache_sync API broken? Just curious at this point.
There are two issues with it:
1. There is no clear buffer ownership definition like it is done for 
   dma_sync_single_for_cpu/device() functions.
2. DMA address argument is missing, which is required for clean and robust implementation 
   on some architectures.

I would like to completely remove dma_cache_sync() and replace it with 
dma_sync_single_for_cpu/device(), but this probably require a bit more discussion and fixing 
all current clients of dma_cache_sync().

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help