mirror of
https://github.com/S3NEO/android_kernel_samsung_msm8226.git
synced 2024-11-07 03:47:13 +00:00
common: DMA-mapping: add DMA_ATTR_SKIP_CPU_SYNC attribute
This patch adds DMA_ATTR_SKIP_CPU_SYNC attribute to the DMA-mapping subsystem. By default dma_map_{single,page,sg} functions family transfer a given buffer from CPU domain to device domain. Some advanced use cases might require sharing a buffer between more than one device. This requires having a mapping created separately for each device and is usually performed by calling dma_map_{single,page,sg} function more than once for the given buffer with device pointer to each device taking part in the buffer sharing. The first call transfers a buffer from 'CPU' domain to 'device' domain, what synchronizes CPU caches for the given region (usually it means that the cache has been flushed or invalidated depending on the dma direction). However, next calls to dma_map_{single,page,sg}() for other devices will perform exactly the same sychronization operation on the CPU cache. CPU cache sychronization might be a time consuming operation, especially if the buffers are large, so it is highly recommended to avoid it if possible. DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of the CPU cache for the given buffer assuming that it has been already transferred to 'device' domain. This attribute can be also used for dma_unmap_{single,page,sg} functions family to force buffer to stay in device domain after releasing a mapping for it. Use this attribute with care! Change-Id: Idac6a165aacb0225aee6aa4c19cd6fb0df6772d5 Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Kyungmin Park <kyungmin.park@samsung.com> Git-commit: bdf5e4871f1b41150236e2337837399109469e65 Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
This commit is contained in:
parent
ac1775c211
commit
70ed0e0299
2 changed files with 26 additions and 0 deletions
|
@ -76,3 +76,28 @@ of mapping (no unaligned accesses, no re-ordering, no write merging, no
|
|||
buffering, no pre-fetching). This has severe performance penalties and
|
||||
should not be used for general purpose DMA allocations. It should only
|
||||
be used if one of the restrictions on strongly ordered memory is required.
|
||||
|
||||
DMA_ATTR_SKIP_CPU_SYNC
|
||||
----------------------
|
||||
|
||||
By default dma_map_{single,page,sg} functions family transfer a given
|
||||
buffer from CPU domain to device domain. Some advanced use cases might
|
||||
require sharing a buffer between more than one device. This requires
|
||||
having a mapping created separately for each device and is usually
|
||||
performed by calling dma_map_{single,page,sg} function more than once
|
||||
for the given buffer with device pointer to each device taking part in
|
||||
the buffer sharing. The first call transfers a buffer from 'CPU' domain
|
||||
to 'device' domain, what synchronizes CPU caches for the given region
|
||||
(usually it means that the cache has been flushed or invalidated
|
||||
depending on the dma direction). However, next calls to
|
||||
dma_map_{single,page,sg}() for other devices will perform exactly the
|
||||
same sychronization operation on the CPU cache. CPU cache sychronization
|
||||
might be a time consuming operation, especially if the buffers are
|
||||
large, so it is highly recommended to avoid it if possible.
|
||||
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
|
||||
the CPU cache for the given buffer assuming that it has been already
|
||||
transferred to 'device' domain. This attribute can be also used for
|
||||
dma_unmap_{single,page,sg} functions family to force buffer to stay in
|
||||
device domain after releasing a mapping for it. Use this attribute with
|
||||
care!
|
||||
|
||||
|
|
|
@ -18,6 +18,7 @@ enum dma_attr {
|
|||
DMA_ATTR_NO_KERNEL_MAPPING,
|
||||
DMA_ATTR_STRONGLY_ORDERED,
|
||||
DMA_ATTR_SKIP_ZEROING,
|
||||
DMA_ATTR_SKIP_CPU_SYNC,
|
||||
DMA_ATTR_MAX,
|
||||
};
|
||||
|
||||
|
|
Loading…
Reference in a new issue