Hi Linus,
I would like to ask for pulling another set of Contiguous Memory Allocator and
DMA-mapping framework updates for v3.8.
The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
Linux 3.7 (2012-12-10 19:30:57 -0800)
are available in the git repository at:
git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.8
for you to fetch changes up to 4009793e15d44469da1547a46ab129cc08ffa503:
drivers: cma: represent physical addresses as phys_addr_t (2012-12-11 09:28:09 +0100)
----------------------------------------------------------------
This pull request consists only of two patches. First fixes long standing
issue with dmapools (the code predates current GIT history), which forced all
allocations to use GFP_ATOMIC flag, ignoring the flags passed by the caller.
The second patch changes CMA code to correctly use phys_addr_t type what
enables support for LPAE systems.
Thanks!
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (1):
mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
Vitaly Andrianov (1):
drivers: cma: represent physical addresses as phys_addr_t
drivers/base/dma-contiguous.c | 24 ++++++++++--------------
include/linux/dma-contiguous.h | 4 ++--
mm/dmapool.c | 31 +++++++------------------------
3 files changed, 19 insertions(+), 40 deletions(-)
The goal of those patches is to allow ION clients (drivers or userland applications)
to use Contiguous Memory Allocator (CMA).
To get more info about CMA:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 8:
- fix memory leak when release sg_table
- remove virt_to_phys from ion_cma_phys
patches version 7:
- rebased on Android kernel
- fix ion Makefile
- add ion_cma_map_kernel function
- remove CONFIG_CMA compilation flags from ion_heap.c
patches version 6:
- add private field in ion_platform_heap to pass the device
linked with CMA.
- rework CMA heap to use private field.
- prepare CMA heap for incoming dma_common_get_sgtable function
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html
- simplify ion-ux500 driver.
patches version 5:
- port patches on android kernel 3.4 where ION use dmabuf
- add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions
patches version 4:
- add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum.
- CMA heap is now a "native" ION heap.
- add ion_heap_create_full function to keep backward compatibilty.
- clean up included files in CMA heap
- ux500-ion is using ion_heap_create_full instead of ion_heap_create
patches version 3:
- add a private field in ion_heap structure instead of expose ion_device
structure to all heaps
- ion_cma_heap is no more a platform driver
- ion_cma_heap use ion_heap private field to store the device pointer and
make the link with reserved CMA regions
- provide ux500-ion driver and configuration file for snowball board to give
an example of how use CMA heaps
patches version 2:
- fix comments done by Andy Green
Benjamin Gaignard (3):
gpu: ion: fix ion_platform_data definition
gpu: ion: add private field in ion_heap and ion_platform_heap
structure
gpu: ion: add CMA heap
drivers/gpu/ion/Kconfig | 5 ++
drivers/gpu/ion/Makefile | 1 +
drivers/gpu/ion/ion_cma_heap.c | 192 ++++++++++++++++++++++++++++++++++++++++
drivers/gpu/ion/ion_heap.c | 7 ++
drivers/gpu/ion/ion_priv.h | 16 ++++
include/linux/ion.h | 7 +-
6 files changed, 227 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/ion/ion_cma_heap.c
--
1.7.10
From: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
The goal of those patches is to allow ION clients (drivers or userland applications)
to use Contiguous Memory Allocator (CMA).
To get more info about CMA:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 7:
- rebased on Android kernel
- fix ion Makefile
- add ion_cma_map_kernel function
- remove CONFIG_CMA compilation flags from ion_heap.c
patches version 6:
- add private field in ion_platform_heap to pass the device
linked with CMA.
- rework CMA heap to use private field.
- prepare CMA heap for incoming dma_common_get_sgtable function
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-June/002109.html
- simplify ion-ux500 driver.
patches version 5:
- port patches on android kernel 3.4 where ION use dmabuf
- add ion_cma_heap_map_dma and ion_cma_heap_unmap_dma functions
patches version 4:
- add ION_HEAP_TYPE_DMA heap type in ion_heap_type enum.
- CMA heap is now a "native" ION heap.
- add ion_heap_create_full function to keep backward compatibilty.
- clean up included files in CMA heap
- ux500-ion is using ion_heap_create_full instead of ion_heap_create
patches version 3:
- add a private field in ion_heap structure instead of expose ion_device
structure to all heaps
- ion_cma_heap is no more a platform driver
- ion_cma_heap use ion_heap private field to store the device pointer and
make the link with reserved CMA regions
- provide ux500-ion driver and configuration file for snowball board to give
an example of how use CMA heaps
patches version 2:
- fix comments done by Andy Green
Benjamin Gaignard (3):
gpu: ion: fix ion_platform_data definition
gpu: ion: add private field in ion_heap and ion_platform_heap
structure
gpu: ion: add CMA heap
drivers/gpu/ion/Kconfig | 5 ++
drivers/gpu/ion/Makefile | 1 +
drivers/gpu/ion/ion_cma_heap.c | 187 ++++++++++++++++++++++++++++++++++++++++
drivers/gpu/ion/ion_heap.c | 7 ++
drivers/gpu/ion/ion_priv.h | 16 ++++
include/linux/ion.h | 7 +-
6 files changed, 222 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/ion/ion_cma_heap.c
--
1.7.10
Hi,
The following APIs are needed for us to support the legacy Tegra
memory manager for devices("NvMap") with *DMA mapping API*.
New API:
->iova_alloc(): To allocate IOVA area.
->iova_alloc_at(): To allocate IOVA area at specific address.
->iova_free(): To free IOVA area.
->map_page_at(): To map page at specific IOVA.
misc:
->iova_get_free_total(): To return how much IOVA is available totally.
->iova_get_free_max(): To return the size of biggest IOVA area.
Although NvMap itself will be replaced soon, there are cases for the
above API where we need to specify IOVA explicitly.
(1) HWAs may require the address for special purpose, like reset vector.
(2) IOVA linear mapping: ex: [RFC 5/5] ARM: dma-mapping: Introduce
dma_map_linear_attrs() for IOVA linear map
(3) To support different heaps. To have allocation and mapping
independently.
Some of them could be supported with creating different mappings, but
currently a device can have a single contiguous mapping, and we cannot
specifiy any address inside of a map since all IOVA alloction is done
implicitly now.
This is the revised version of:
http://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001947.htmlhttp://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001948.htmlhttp://lists.linaro.org/pipermail/linaro-mm-sig/2012-May/001949.html
Any comment would be really appreciated.
Hiroshi Doyu (5):
ARM: dma-mapping: New dma_map_ops->iova_get_free_{total,max}
functions
ARM: dma-mapping: New dma_map_ops->iova_{alloc,free}() functions
ARM: dma-mapping: New dma_map_ops->iova_alloc*_at* function
ARM: dma-mapping: New dma_map_ops->map_page*_at* function
ARM: dma-mapping: Introduce dma_map_linear_attrs() for IOVA linear
map
arch/arm/include/asm/dma-mapping.h | 55 +++++++++++++
arch/arm/mm/dma-mapping.c | 124 ++++++++++++++++++++++++++++++
include/asm-generic/dma-mapping-common.h | 20 +++++
include/linux/dma-mapping.h | 14 ++++
4 files changed, 213 insertions(+), 0 deletions(-)
--
1.7.5.4