[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

Hi,

There's been some recent discussions[1] about Ion-like frameworks. There's
apparently interest in just keeping Ion since it works reasonablly well.
This series does what should be the final clean ups for it to possibly be
moved out of staging.

This includes the following:
- Some general clean up and removal of features that never got a lot of use
  as far as I can tell.
- Fixing up the caching. This is the series I proposed back in December[2]
  but never heard any feedback on. It will certainly break existing
  applications that rely on the implicit caching. I'd rather make an effort
  to move to a model that isn't going directly against the establishement
  though.
- Fixing up the platform support. The devicetree approach was never well
  recieved by DT maintainers. The proposal here is to think of Ion less as
  specifying requirements and more of a framework for exposing memory to
  userspace.
- CMA allocations now happen without the need of a dummy device structure.
  This fixes a bunch of the reasons why I attempted to add devicetree
  support before.

I've had problems getting feedback in the past so if I don't hear any major
objections I'm going to send out with the RFC dropped to be picked up.
The only reason there isn't a patch to come out of staging is to discuss any
other changes to the ABI people might want. Once this comes out of staging,
I really don't want to mess with the ABI.

Feedback appreciated.

Thanks,
Laura

[1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
[2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2

Laura Abbott (12):
  staging: android: ion: Remove dmap_cnt
  staging: android: ion: Remove alignment from allocation field
  staging: android: ion: Duplicate sg_table
  staging: android: ion: Call dma_map_sg for syncing and mapping
  staging: android: ion: Remove page faulting support
  staging: android: ion: Remove crufty cache support
  staging: android: ion: Remove old platform support
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Make Ion heaps selectable
  staging; android: ion: Enumerate all available heaps

 drivers/base/dma-contiguous.c                      |   5 +-
 drivers/staging/android/ion/Kconfig                |  51 ++--
 drivers/staging/android/ion/Makefile               |  14 +-
 drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
 drivers/staging/android/ion/hisilicon/Makefile     |   1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
 drivers/staging/android/ion/ion-ioctl.c            |   6 -
 drivers/staging/android/ion/ion.c                  | 282 ++++++---------------
 drivers/staging/android/ion/ion.h                  |   5 +-
 drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
 drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
 drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
 drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
 drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
 drivers/staging/android/ion/ion_of.c               | 184 --------------
 drivers/staging/android/ion/ion_of.h               |  37 ---
 drivers/staging/android/ion/ion_page_pool.c        |   3 -
 drivers/staging/android/ion/ion_priv.h             |  57 ++++-
 drivers/staging/android/ion/ion_system_heap.c      |  14 +-
 drivers/staging/android/ion/tegra/Makefile         |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
 include/linux/cma.h                                |   6 +-
 mm/cma.c                                           |  25 +-
 mm/cma.h                                           |   1 +
 mm/cma_debug.c                                     |   2 +-
 25 files changed, 312 insertions(+), 958 deletions(-)
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 create mode 100644 drivers/staging/android/ion/ion_enumerate.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
2.7.4

[RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt

[Laura Abbott]

The reference counting of dma_map calls was removed. Remove the
associated counter field as well.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion_priv.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index 5b3059c..46d3ff5 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -44,7 +44,6 @@
  * @lock:		protects the buffers cnt fields
  * @kmap_cnt:		number of times the buffer is mapped to the kernel
  * @vaddr:		the kernel mapping if kmap_cnt is not zero
- * @dmap_cnt:		number of times the buffer is mapped for dma
  * @sg_table:		the sg table for the buffer if dmap_cnt is not zero
  * @pages:		flat array of pages in the buffer -- used by fault
  *			handler and only valid for buffers that are faulted in
@@ -70,7 +69,6 @@ struct ion_buffer {
 	struct mutex lock;
 	int kmap_cnt;
 	void *vaddr;
-	int dmap_cnt;
 	struct sg_table *sg_table;
 	struct page **pages;
 	struct list_head vmas;
-- 
2.7.4

[RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field

[Laura Abbott]

The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c         |  1 -
 drivers/staging/android/ion/ion.c               | 14 ++++++--------
 drivers/staging/android/ion/ion.h               |  5 +----
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +++-------
 drivers/staging/android/ion/ion_chunk_heap.c    |  9 +++------
 drivers/staging/android/ion/ion_cma_heap.c      |  5 +----
 drivers/staging/android/ion/ion_priv.h          |  2 +-
 drivers/staging/android/ion/ion_system_heap.c   |  9 +--------
 8 files changed, 16 insertions(+), 39 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index 9ff815a..5b2e93f 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 		struct ion_handle *handle;
 
 		handle = ion_alloc(client, data.allocation.len,
-						data.allocation.align,
 						data.allocation.heap_id_mask,
 						data.allocation.flags);
 		if (IS_ERR(handle))
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 9696007..94a498e 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
 static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
 					    struct ion_device *dev,
 					    unsigned long len,
-					    unsigned long align,
 					    unsigned long flags)
 {
 	struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
 	buffer->flags = flags;
 	kref_init(&buffer->ref);
 
-	ret = heap->ops->allocate(heap, buffer, len, align, flags);
+	ret = heap->ops->allocate(heap, buffer, len, flags);
 
 	if (ret) {
 		if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
 			goto err2;
 
 		ion_heap_freelist_drain(heap, 0);
-		ret = heap->ops->allocate(heap, buffer, len, align,
-					  flags);
+		ret = heap->ops->allocate(heap, buffer, len, flags);
 		if (ret)
 			goto err2;
 	}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct ion_handle *handle)
 }
 
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-			     size_t align, unsigned int heap_id_mask,
+			     unsigned int heap_id_mask,
 			     unsigned int flags)
 {
 	struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
 	struct ion_heap *heap;
 	int ret;
 
-	pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
-		 len, align, heap_id_mask, flags);
+	pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+		 len, heap_id_mask, flags);
 	/*
 	 * traverse the list of heaps available in this system in priority
 	 * order.  If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
 		/* if the caller didn't specify this heap id */
 		if (!((1 << heap->id) & heap_id_mask))
 			continue;
-		buffer = ion_buffer_create(heap, dev, len, align, flags);
+		buffer = ion_buffer_create(heap, dev, len, flags);
 		if (!IS_ERR(buffer))
 			break;
 	}
diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
index 93dafb4..3b4bff5 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -45,7 +45,6 @@ struct ion_buffer;
  * @name:	used for debug purposes
  * @base:	base address of heap in physical memory if applicable
  * @size:	size of the heap in bytes if applicable
- * @align:	required alignment in physical memory if applicable
  * @priv:	private info passed from the board file
  *
  * Provided by the board file.
@@ -93,8 +92,6 @@ void ion_client_destroy(struct ion_client *client);
  * ion_alloc - allocate ion memory
  * @client:		the client
  * @len:		size of the allocation
- * @align:		requested allocation alignment, lots of hardware blocks
- *			have alignment requirements of some kind
  * @heap_id_mask:	mask of heaps to allocate from, if multiple bits are set
  *			heaps will be tried in order from highest to lowest
  *			id
@@ -106,7 +103,7 @@ void ion_client_destroy(struct ion_client *client);
  * an opaque handle to it.
  */
 struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
-			     size_t align, unsigned int heap_id_mask,
+			     unsigned int heap_id_mask,
 			     unsigned int flags);
 
 /**
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c
index a8ea973..9bf8e98 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -34,8 +34,7 @@ struct ion_carveout_heap {
 };
 
 static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
-					     unsigned long size,
-					     unsigned long align)
+					     unsigned long size)
 {
 	struct ion_carveout_heap *carveout_heap =
 		container_of(heap, struct ion_carveout_heap, heap);
@@ -60,16 +59,13 @@ static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
 
 static int ion_carveout_heap_allocate(struct ion_heap *heap,
 				      struct ion_buffer *buffer,
-				      unsigned long size, unsigned long align,
+				      unsigned long size,
 				      unsigned long flags)
 {
 	struct sg_table *table;
 	ion_phys_addr_t paddr;
 	int ret;
 
-	if (align > PAGE_SIZE)
-		return -EINVAL;
-
 	table = kmalloc(sizeof(*table), GFP_KERNEL);
 	if (!table)
 		return -ENOMEM;
@@ -77,7 +73,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
 	if (ret)
 		goto err_free;
 
-	paddr = ion_carveout_allocate(heap, size, align);
+	paddr = ion_carveout_allocate(heap, size);
 	if (paddr == ION_CARVEOUT_ALLOCATE_FAIL) {
 		ret = -ENOMEM;
 		goto err_free_table;
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c b/drivers/staging/android/ion/ion_chunk_heap.c
index 70495dc..8c41889 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -35,7 +35,7 @@ struct ion_chunk_heap {
 
 static int ion_chunk_heap_allocate(struct ion_heap *heap,
 				   struct ion_buffer *buffer,
-				   unsigned long size, unsigned long align,
+				   unsigned long size,
 				   unsigned long flags)
 {
 	struct ion_chunk_heap *chunk_heap =
@@ -46,9 +46,6 @@ static int ion_chunk_heap_allocate(struct ion_heap *heap,
 	unsigned long num_chunks;
 	unsigned long allocated_size;
 
-	if (align > chunk_heap->chunk_size)
-		return -EINVAL;
-
 	allocated_size = ALIGN(size, chunk_heap->chunk_size);
 	num_chunks = allocated_size / chunk_heap->chunk_size;
 
@@ -160,8 +157,8 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
 	chunk_heap->heap.ops = &chunk_heap_ops;
 	chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
 	chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
-	pr_debug("%s: base %lu size %zu align %ld\n", __func__,
-		 chunk_heap->base, heap_data->size, heap_data->align);
+	pr_debug("%s: base %lu size %zu \n", __func__,
+		 chunk_heap->base, heap_data->size);
 
 	return &chunk_heap->heap;
 
diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index 6c40685..d562fd7 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -40,7 +40,7 @@ struct ion_cma_buffer_info {
 
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
-			    unsigned long len, unsigned long align,
+			    unsigned long len,
 			    unsigned long flags)
 {
 	struct ion_cma_heap *cma_heap = to_cma_heap(heap);
@@ -52,9 +52,6 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
 	if (buffer->flags & ION_FLAG_CACHED)
 		return -EINVAL;
 
-	if (align > PAGE_SIZE)
-		return -EINVAL;
-
 	info = kzalloc(sizeof(*info), GFP_KERNEL);
 	if (!info)
 		return -ENOMEM;
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index 46d3ff5..b09bc7c 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -172,7 +172,7 @@ struct ion_handle {
 struct ion_heap_ops {
 	int (*allocate)(struct ion_heap *heap,
 			struct ion_buffer *buffer, unsigned long len,
-			unsigned long align, unsigned long flags);
+			unsigned long flags);
 	void (*free)(struct ion_buffer *buffer);
 	void * (*map_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
 	void (*unmap_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index 3ebbb75..6cb2fe7 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -129,7 +129,7 @@ static struct page *alloc_largest_available(struct ion_system_heap *heap,
 
 static int ion_system_heap_allocate(struct ion_heap *heap,
 				    struct ion_buffer *buffer,
-				    unsigned long size, unsigned long align,
+				    unsigned long size,
 				    unsigned long flags)
 {
 	struct ion_system_heap *sys_heap = container_of(heap,
@@ -143,9 +143,6 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
 	unsigned long size_remaining = PAGE_ALIGN(size);
 	unsigned int max_order = orders[0];
 
-	if (align > PAGE_SIZE)
-		return -EINVAL;
-
 	if (size / PAGE_SIZE > totalram_pages / 2)
 		return -ENOMEM;
 
@@ -372,7 +369,6 @@ void ion_system_heap_destroy(struct ion_heap *heap)
 static int ion_system_contig_heap_allocate(struct ion_heap *heap,
 					   struct ion_buffer *buffer,
 					   unsigned long len,
-					   unsigned long align,
 					   unsigned long flags)
 {
 	int order = get_order(len);
@@ -381,9 +377,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
 	unsigned long i;
 	int ret;
 
-	if (align > (PAGE_SIZE << order))
-		return -EINVAL;
-
 	page = alloc_pages(low_order_gfp_flags, order);
 	if (!page)
 		return -ENOMEM;
-- 
2.7.4

[RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Laura Abbott]

Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 94a498e..ce4adac 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -799,6 +799,32 @@ static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
 				       struct device *dev,
 				       enum dma_data_direction direction);
 
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+	struct sg_table *new_table;
+	int ret, i;
+	struct scatterlist *sg, *new_sg;
+
+	new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+	if (!new_table)
+		return ERR_PTR(-ENOMEM);
+
+	ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+	if (ret) {
+		kfree(table);
+		return ERR_PTR(-ENOMEM);
+	}
+
+	new_sg = new_table->sgl;
+	for_each_sg(table->sgl, sg, table->nents, i) {
+		memcpy(new_sg, sg, sizeof(*sg));
+		sg->dma_address = 0;
+		new_sg = sg_next(new_sg);
+	}
+
+	return new_table;
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
 					enum dma_data_direction direction)
 {
@@ -806,13 +832,15 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
 	struct ion_buffer *buffer = dmabuf->priv;
 
 	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-	return buffer->sg_table;
+	return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
 			      struct sg_table *table,
 			      enum dma_data_direction direction)
 {
+	sg_free_table(table);
+	kfree(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-- 
2.7.4

[RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion.c | 101 +++++++++++++++++++-------------------
 1 file changed, 50 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index ce4adac..a931b30 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
 }
 EXPORT_SYMBOL(ion_client_destroy);
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-				       struct device *dev,
-				       enum dma_data_direction direction);
-
 static struct sg_table *dup_sg_table(struct sg_table *table)
 {
 	struct sg_table *new_table;
@@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table *table)
 	return new_table;
 }
 
+static void free_duped_table(struct sg_table *table)
+{
+	sg_free_table(table);
+	kfree(table);
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
 					enum dma_data_direction direction)
 {
 	struct dma_buf *dmabuf = attachment->dmabuf;
 	struct ion_buffer *buffer = dmabuf->priv;
+	struct sg_table *table;
+	int ret;
+
+	/*
+	 * TODO: Need to sync wrt CPU or device completely owning?
+	 */
+
+	table = dup_sg_table(buffer->sg_table);
 
-	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-	return dup_sg_table(buffer->sg_table);
+	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+			direction)){
+		ret = -ENOMEM;
+		goto err;
+	}
+
+err:
+	free_duped_table(table);
+	return ERR_PTR(ret);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
 			      struct sg_table *table,
 			      enum dma_data_direction direction)
 {
-	sg_free_table(table);
-	kfree(table);
+	dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+	free_duped_table(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -864,38 +881,6 @@ struct ion_vma_list {
 	struct vm_area_struct *vma;
 };
 
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
-				       struct device *dev,
-				       enum dma_data_direction dir)
-{
-	struct ion_vma_list *vma_list;
-	int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-	int i;
-
-	pr_debug("%s: syncing for device %s\n", __func__,
-		 dev ? dev_name(dev) : "null");
-
-	if (!ion_buffer_fault_user_mappings(buffer))
-		return;
-
-	mutex_lock(&buffer->lock);
-	for (i = 0; i < pages; i++) {
-		struct page *page = buffer->pages[i];
-
-		if (ion_buffer_page_is_dirty(page))
-			ion_pages_sync_for_device(dev, ion_buffer_page(page),
-						  PAGE_SIZE, dir);
-
-		ion_buffer_page_clean(buffer->pages + i);
-	}
-	list_for_each_entry(vma_list, &buffer->vmas, list) {
-		struct vm_area_struct *vma = vma_list->vma;
-
-		zap_page_range(vma, vma->vm_start, vma->vm_end - vma->vm_start);
-	}
-	mutex_unlock(&buffer->lock);
-}
-
 static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
 {
 	struct ion_buffer *buffer = vma->vm_private_data;
@@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 	struct ion_buffer *buffer = dmabuf->priv;
 	void *vaddr;
 
-	if (!buffer->heap->ops->map_kernel) {
-		pr_err("%s: map kernel is not implemented by this heap.\n",
-		       __func__);
-		return -ENODEV;
+	/*
+	 * TODO: Move this elsewhere because we don't always need a vaddr
+	 */
+	if (buffer->heap->ops->map_kernel) {
+		mutex_lock(&buffer->lock);
+		vaddr = ion_buffer_kmap_get(buffer);
+		mutex_unlock(&buffer->lock);
 	}
 
-	mutex_lock(&buffer->lock);
-	vaddr = ion_buffer_kmap_get(buffer);
-	mutex_unlock(&buffer->lock);
-	return PTR_ERR_OR_ZERO(vaddr);
+	/*
+	 * Close enough right now? Flag to skip sync?
+	 */
+	if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+			buffer->sg_table->nents,
+                        DMA_BIDIRECTIONAL))
+		return -ENOMEM;
+
+	return 0;
 }
 
 static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -1031,9 +1024,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
 {
 	struct ion_buffer *buffer = dmabuf->priv;
 
-	mutex_lock(&buffer->lock);
-	ion_buffer_kmap_put(buffer);
-	mutex_unlock(&buffer->lock);
+	if (buffer->heap->ops->map_kernel) {
+		mutex_lock(&buffer->lock);
+		ion_buffer_kmap_put(buffer);
+		mutex_unlock(&buffer->lock);
+	}
+
+	dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+			buffer->sg_table->nents,
+			DMA_BIDIRECTIONAL);
 
 	return 0;
 }
-- 
2.7.4

[RFC PATCH 05/12] staging: android: ion: Remove page faulting support

[Laura Abbott]

The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion.c | 117 --------------------------------------
 1 file changed, 117 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index a931b30..8eef1d7 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
 #include "ion_priv.h"
 #include "compat_ion.h"
 
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
-	return (buffer->flags & ION_FLAG_CACHED) &&
-		!(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
 	return !!(buffer->flags & ION_FLAG_CACHED);
 }
 
-static inline struct page *ion_buffer_page(struct page *page)
-{
-	return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
-	return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
-	*page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
-	*page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
 /* this function should only be called while dev->lock is held */
 static void ion_buffer_add(struct ion_device *dev,
 			   struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
 	buffer->dev = dev;
 	buffer->size = len;
 
-	if (ion_buffer_fault_user_mappings(buffer)) {
-		int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
-		struct scatterlist *sg;
-		int i, j, k = 0;
-
-		buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
-		if (!buffer->pages) {
-			ret = -ENOMEM;
-			goto err1;
-		}
-
-		for_each_sg(table->sgl, sg, table->nents, i) {
-			struct page *page = sg_page(sg);
-
-			for (j = 0; j < sg->length / PAGE_SIZE; j++)
-				buffer->pages[k++] = page++;
-		}
-	}
-
 	buffer->dev = dev;
 	buffer->size = len;
 	INIT_LIST_HEAD(&buffer->vmas);
@@ -876,69 +831,6 @@ void ion_pages_sync_for_device(struct device *dev, struct page *page,
 	dma_sync_sg_for_device(dev, &sg, 1, dir);
 }
 
-struct ion_vma_list {
-	struct list_head list;
-	struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
-	struct ion_buffer *buffer = vma->vm_private_data;
-	unsigned long pfn;
-	int ret;
-
-	mutex_lock(&buffer->lock);
-	ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
-	BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
-	pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
-	ret = vm_insert_pfn(vma, vmf->address, pfn);
-	mutex_unlock(&buffer->lock);
-	if (ret)
-		return VM_FAULT_ERROR;
-
-	return VM_FAULT_NOPAGE;
-}
-
-static void ion_vm_open(struct vm_area_struct *vma)
-{
-	struct ion_buffer *buffer = vma->vm_private_data;
-	struct ion_vma_list *vma_list;
-
-	vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
-	if (!vma_list)
-		return;
-	vma_list->vma = vma;
-	mutex_lock(&buffer->lock);
-	list_add(&vma_list->list, &buffer->vmas);
-	mutex_unlock(&buffer->lock);
-	pr_debug("%s: adding %p\n", __func__, vma);
-}
-
-static void ion_vm_close(struct vm_area_struct *vma)
-{
-	struct ion_buffer *buffer = vma->vm_private_data;
-	struct ion_vma_list *vma_list, *tmp;
-
-	pr_debug("%s\n", __func__);
-	mutex_lock(&buffer->lock);
-	list_for_each_entry_safe(vma_list, tmp, &buffer->vmas, list) {
-		if (vma_list->vma != vma)
-			continue;
-		list_del(&vma_list->list);
-		kfree(vma_list);
-		pr_debug("%s: deleting %p\n", __func__, vma);
-		break;
-	}
-	mutex_unlock(&buffer->lock);
-}
-
-static const struct vm_operations_struct ion_vma_ops = {
-	.open = ion_vm_open,
-	.close = ion_vm_close,
-	.fault = ion_vm_fault,
-};
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
 	struct ion_buffer *buffer = dmabuf->priv;
@@ -950,15 +842,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 		return -EINVAL;
 	}
 
-	if (ion_buffer_fault_user_mappings(buffer)) {
-		vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
-							VM_DONTDUMP;
-		vma->vm_private_data = buffer;
-		vma->vm_ops = &ion_vma_ops;
-		ion_vm_open(vma);
-		return 0;
-	}
-
 	if (!(buffer->flags & ION_FLAG_CACHED))
 		vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
 
-- 
2.7.4

[RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laura Abbott]

Now that we call dma_map in the dma_buf API callbacks there is no need
to use the existing cache APIs. Remove the sync ioctl and the existing
bad dma_sync calls. Explicit caching can be handled with the dma_buf
sync API.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c         |  5 ----
 drivers/staging/android/ion/ion.c               | 40 -------------------------
 drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
 drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
 drivers/staging/android/ion/ion_page_pool.c     |  3 --
 drivers/staging/android/ion/ion_system_heap.c   |  5 ----
 6 files changed, 65 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..f820d77 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 			data.handle.handle = handle->id;
 		break;
 	}
-	case ION_IOC_SYNC:
-	{
-		ret = ion_sync_for_device(client, data.fd.fd);
-		break;
-	}
 	case ION_IOC_CUSTOM:
 	{
 		if (!dev->custom_ioctl)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 8eef1d7..c3c316f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
 	free_duped_table(table);
 }
 
-void ion_pages_sync_for_device(struct device *dev, struct page *page,
-			       size_t size, enum dma_data_direction dir)
-{
-	struct scatterlist sg;
-
-	sg_init_table(&sg, 1);
-	sg_set_page(&sg, page, size, 0);
-	/*
-	 * This is not correct - sg_dma_address needs a dma_addr_t that is valid
-	 * for the targeted device, but this works on the currently targeted
-	 * hardware.
-	 */
-	sg_dma_address(&sg) = page_to_phys(page);
-	dma_sync_sg_for_device(dev, &sg, 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
 	struct ion_buffer *buffer = dmabuf->priv;
@@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
 }
 EXPORT_SYMBOL(ion_import_dma_buf_fd);
 
-int ion_sync_for_device(struct ion_client *client, int fd)
-{
-	struct dma_buf *dmabuf;
-	struct ion_buffer *buffer;
-
-	dmabuf = dma_buf_get(fd);
-	if (IS_ERR(dmabuf))
-		return PTR_ERR(dmabuf);
-
-	/* if this memory came from ion */
-	if (dmabuf->ops != &dma_buf_ops) {
-		pr_err("%s: can not sync dmabuf from another exporter\n",
-		       __func__);
-		dma_buf_put(dmabuf);
-		return -EINVAL;
-	}
-	buffer = dmabuf->priv;
-
-	dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
-			       buffer->sg_table->nents, DMA_BIDIRECTIONAL);
-	dma_buf_put(dmabuf);
-	return 0;
-}
-
 int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
 {
 	struct ion_device *dev = client->dev;
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c
index 9bf8e98..e0e360f 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
 
 	ion_heap_buffer_zero(buffer);
 
-	if (ion_buffer_cached(buffer))
-		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
-				       DMA_BIDIRECTIONAL);
-
 	ion_carveout_free(heap, paddr, buffer->size);
 	sg_free_table(table);
 	kfree(table);
@@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data)
 	page = pfn_to_page(PFN_DOWN(heap_data->base));
 	size = heap_data->size;
 
-	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
-
 	ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
 	if (ret)
 		return ERR_PTR(ret);
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c b/drivers/staging/android/ion/ion_chunk_heap.c
index 8c41889..46e13f6 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -101,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer *buffer)
 
 	ion_heap_buffer_zero(buffer);
 
-	if (ion_buffer_cached(buffer))
-		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
-				       DMA_BIDIRECTIONAL);
-
 	for_each_sg(table->sgl, sg, table->nents, i) {
 		gen_pool_free(chunk_heap->pool, page_to_phys(sg_page(sg)),
 			      sg->length);
@@ -132,8 +128,6 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
 	page = pfn_to_page(PFN_DOWN(heap_data->base));
 	size = heap_data->size;
 
-	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
-
 	ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
 	if (ret)
 		return ERR_PTR(ret);
diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
index aea89c1..532eda7 100644
--- a/drivers/staging/android/ion/ion_page_pool.c
+++ b/drivers/staging/android/ion/ion_page_pool.c
@@ -30,9 +30,6 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
 
 	if (!page)
 		return NULL;
-	if (!pool->cached)
-		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
-					  DMA_BIDIRECTIONAL);
 	return page;
 }
 
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index 6cb2fe7..a33331b 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -75,9 +75,6 @@ static struct page *alloc_buffer_page(struct ion_system_heap *heap,
 
 	page = ion_page_pool_alloc(pool);
 
-	if (cached)
-		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
-					  DMA_BIDIRECTIONAL);
 	return page;
 }
 
@@ -401,8 +398,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
 
 	buffer->sg_table = table;
 
-	ion_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
-
 	return 0;
 
 free_table:
-- 
2.7.4

[RFC PATCH 07/12] staging: android: ion: Remove old platform support

[Laura Abbott]

Device specific platform support has been haphazard for Ion. There have
been several independent attempts and there are still objections to
what bindings exist right now. Just remove everything for a fresh start.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/Kconfig                |  35 ----
 drivers/staging/android/ion/Makefile               |   6 -
 drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
 drivers/staging/android/ion/hisilicon/Makefile     |   1 -
 drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -------------
 drivers/staging/android/ion/ion_dummy_driver.c     | 156 -----------------
 drivers/staging/android/ion/ion_of.c               | 184 ---------------------
 drivers/staging/android/ion/ion_of.h               |  37 -----
 drivers/staging/android/ion/tegra/Makefile         |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ---------
 10 files changed, 618 deletions(-)
 delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
 delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
 delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
 delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
 delete mode 100644 drivers/staging/android/ion/ion_of.c
 delete mode 100644 drivers/staging/android/ion/ion_of.h
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index c8fb413..0c91b2b 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,38 +17,3 @@ config ION_TEST
 	  Choose this option to create a device that can be used to test the
 	  kernel and device side ION functions.
 
-config ION_DUMMY
-	bool "Dummy Ion driver"
-	depends on ION
-	help
-	  Provides a dummy ION driver that registers the
-	  /dev/ion device and some basic heaps. This can
-	  be used for testing the ION infrastructure if
-	  one doesn't have access to hardware drivers that
-	  use ION.
-
-config ION_TEGRA
-	tristate "Ion for Tegra"
-	depends on ARCH_TEGRA && ION
-	help
-	  Choose this option if you wish to use ion on an nVidia Tegra.
-
-config ION_HISI
-	tristate "Ion for Hisilicon"
-	depends on ARCH_HISI && ION
-	select ION_OF
-	help
-	  Choose this option if you wish to use ion on Hisilicon Platform.
-
-source "drivers/staging/android/ion/hisilicon/Kconfig"
-
-config ION_OF
-	bool "Devicetree support for Ion"
-	depends on ION && OF_ADDRESS
-	help
-	  Provides base support for defining Ion heaps in devicetree
-	  and setting them up. Also includes functions for platforms
-	  to parse the devicetree and expand for their own custom
-	  extensions
-
-	  If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index 5d630a0..9457090 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,9 +5,3 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
-
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-obj-$(CONFIG_ION_HISI) += hisilicon/
-obj-$(CONFIG_ION_OF) += ion_of.o
-
diff --git a/drivers/staging/android/ion/hisilicon/Kconfig b/drivers/staging/android/ion/hisilicon/Kconfig
deleted file mode 100644
index 2b4bd07..0000000
--- a/drivers/staging/android/ion/hisilicon/Kconfig
+++ /dev/null
@@ -1,5 +0,0 @@
-config HI6220_ION
-        bool "Hi6220 ION Driver"
-        depends on ARCH_HISI && ION
-        help
-          Build the Hisilicon Hi6220 ion driver.
diff --git a/drivers/staging/android/ion/hisilicon/Makefile b/drivers/staging/android/ion/hisilicon/Makefile
deleted file mode 100644
index 2a89414..0000000
--- a/drivers/staging/android/ion/hisilicon/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
deleted file mode 100644
index 0de7897..0000000
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ /dev/null
@@ -1,113 +0,0 @@
-/*
- * Hisilicon Hi6220 ION Driver
- *
- * Copyright (c) 2015 Hisilicon Limited.
- *
- * Author: Chen Feng <puck.chen@hisilicon.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#define pr_fmt(fmt) "Ion: " fmt
-
-#include <linux/err.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/of.h>
-#include <linux/mm.h>
-#include "../ion_priv.h"
-#include "../ion.h"
-#include "../ion_of.h"
-
-struct hisi_ion_dev {
-	struct ion_heap	**heaps;
-	struct ion_device *idev;
-	struct ion_platform_data *data;
-};
-
-static struct ion_of_heap hisi_heaps[] = {
-	PLATFORM_HEAP("hisilicon,sys_user", 0,
-		      ION_HEAP_TYPE_SYSTEM, "sys_user"),
-	PLATFORM_HEAP("hisilicon,sys_contig", 1,
-		      ION_HEAP_TYPE_SYSTEM_CONTIG, "sys_contig"),
-	PLATFORM_HEAP("hisilicon,cma", ION_HEAP_TYPE_DMA, ION_HEAP_TYPE_DMA,
-		      "cma"),
-	{}
-};
-
-static int hi6220_ion_probe(struct platform_device *pdev)
-{
-	struct hisi_ion_dev *ipdev;
-	int i;
-
-	ipdev = devm_kzalloc(&pdev->dev, sizeof(*ipdev), GFP_KERNEL);
-	if (!ipdev)
-		return -ENOMEM;
-
-	platform_set_drvdata(pdev, ipdev);
-
-	ipdev->idev = ion_device_create(NULL);
-	if (IS_ERR(ipdev->idev))
-		return PTR_ERR(ipdev->idev);
-
-	ipdev->data = ion_parse_dt(pdev, hisi_heaps);
-	if (IS_ERR(ipdev->data))
-		return PTR_ERR(ipdev->data);
-
-	ipdev->heaps = devm_kzalloc(&pdev->dev,
-				sizeof(struct ion_heap) * ipdev->data->nr,
-				GFP_KERNEL);
-	if (!ipdev->heaps) {
-		ion_destroy_platform_data(ipdev->data);
-		return -ENOMEM;
-	}
-
-	for (i = 0; i < ipdev->data->nr; i++) {
-		ipdev->heaps[i] = ion_heap_create(&ipdev->data->heaps[i]);
-		if (!ipdev->heaps) {
-			ion_destroy_platform_data(ipdev->data);
-			return -ENOMEM;
-		}
-		ion_device_add_heap(ipdev->idev, ipdev->heaps[i]);
-	}
-	return 0;
-}
-
-static int hi6220_ion_remove(struct platform_device *pdev)
-{
-	struct hisi_ion_dev *ipdev;
-	int i;
-
-	ipdev = platform_get_drvdata(pdev);
-
-	for (i = 0; i < ipdev->data->nr; i++)
-		ion_heap_destroy(ipdev->heaps[i]);
-
-	ion_destroy_platform_data(ipdev->data);
-	ion_device_destroy(ipdev->idev);
-
-	return 0;
-}
-
-static const struct of_device_id hi6220_ion_match_table[] = {
-	{.compatible = "hisilicon,hi6220-ion"},
-	{},
-};
-
-static struct platform_driver hi6220_ion_driver = {
-	.probe = hi6220_ion_probe,
-	.remove = hi6220_ion_remove,
-	.driver = {
-		.name = "ion-hi6220",
-		.of_match_table = hi6220_ion_match_table,
-	},
-};
-
-static int __init hi6220_ion_init(void)
-{
-	return platform_driver_register(&hi6220_ion_driver);
-}
-
-subsys_initcall(hi6220_ion_init);
diff --git a/drivers/staging/android/ion/ion_dummy_driver.c b/drivers/staging/android/ion/ion_dummy_driver.c
deleted file mode 100644
index cf5c010..0000000
--- a/drivers/staging/android/ion/ion_dummy_driver.c
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * drivers/gpu/ion/ion_dummy_driver.c
- *
- * Copyright (C) 2013 Linaro, Inc
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/err.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/init.h>
-#include <linux/bootmem.h>
-#include <linux/memblock.h>
-#include <linux/sizes.h>
-#include <linux/io.h>
-#include "ion.h"
-#include "ion_priv.h"
-
-static struct ion_device *idev;
-static struct ion_heap **heaps;
-
-static void *carveout_ptr;
-static void *chunk_ptr;
-
-static struct ion_platform_heap dummy_heaps[] = {
-		{
-			.id	= ION_HEAP_TYPE_SYSTEM,
-			.type	= ION_HEAP_TYPE_SYSTEM,
-			.name	= "system",
-		},
-		{
-			.id	= ION_HEAP_TYPE_SYSTEM_CONTIG,
-			.type	= ION_HEAP_TYPE_SYSTEM_CONTIG,
-			.name	= "system contig",
-		},
-		{
-			.id	= ION_HEAP_TYPE_CARVEOUT,
-			.type	= ION_HEAP_TYPE_CARVEOUT,
-			.name	= "carveout",
-			.size	= SZ_4M,
-		},
-		{
-			.id	= ION_HEAP_TYPE_CHUNK,
-			.type	= ION_HEAP_TYPE_CHUNK,
-			.name	= "chunk",
-			.size	= SZ_4M,
-			.align	= SZ_16K,
-			.priv	= (void *)(SZ_16K),
-		},
-};
-
-static const struct ion_platform_data dummy_ion_pdata = {
-	.nr = ARRAY_SIZE(dummy_heaps),
-	.heaps = dummy_heaps,
-};
-
-static int __init ion_dummy_init(void)
-{
-	int i, err;
-
-	idev = ion_device_create(NULL);
-	if (IS_ERR(idev))
-		return PTR_ERR(idev);
-	heaps = kcalloc(dummy_ion_pdata.nr, sizeof(struct ion_heap *),
-			GFP_KERNEL);
-	if (!heaps)
-		return -ENOMEM;
-
-
-	/* Allocate a dummy carveout heap */
-	carveout_ptr = alloc_pages_exact(
-				dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size,
-				GFP_KERNEL);
-	if (carveout_ptr)
-		dummy_heaps[ION_HEAP_TYPE_CARVEOUT].base =
-						virt_to_phys(carveout_ptr);
-	else
-		pr_err("ion_dummy: Could not allocate carveout\n");
-
-	/* Allocate a dummy chunk heap */
-	chunk_ptr = alloc_pages_exact(
-				dummy_heaps[ION_HEAP_TYPE_CHUNK].size,
-				GFP_KERNEL);
-	if (chunk_ptr)
-		dummy_heaps[ION_HEAP_TYPE_CHUNK].base = virt_to_phys(chunk_ptr);
-	else
-		pr_err("ion_dummy: Could not allocate chunk\n");
-
-	for (i = 0; i < dummy_ion_pdata.nr; i++) {
-		struct ion_platform_heap *heap_data = &dummy_ion_pdata.heaps[i];
-
-		if (heap_data->type == ION_HEAP_TYPE_CARVEOUT &&
-		    !heap_data->base)
-			continue;
-
-		if (heap_data->type == ION_HEAP_TYPE_CHUNK && !heap_data->base)
-			continue;
-
-		heaps[i] = ion_heap_create(heap_data);
-		if (IS_ERR_OR_NULL(heaps[i])) {
-			err = PTR_ERR(heaps[i]);
-			goto err;
-		}
-		ion_device_add_heap(idev, heaps[i]);
-	}
-	return 0;
-err:
-	for (i = 0; i < dummy_ion_pdata.nr; ++i)
-		ion_heap_destroy(heaps[i]);
-	kfree(heaps);
-
-	if (carveout_ptr) {
-		free_pages_exact(carveout_ptr,
-				 dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
-		carveout_ptr = NULL;
-	}
-	if (chunk_ptr) {
-		free_pages_exact(chunk_ptr,
-				 dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
-		chunk_ptr = NULL;
-	}
-	return err;
-}
-device_initcall(ion_dummy_init);
-
-static void __exit ion_dummy_exit(void)
-{
-	int i;
-
-	ion_device_destroy(idev);
-
-	for (i = 0; i < dummy_ion_pdata.nr; i++)
-		ion_heap_destroy(heaps[i]);
-	kfree(heaps);
-
-	if (carveout_ptr) {
-		free_pages_exact(carveout_ptr,
-				 dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
-		carveout_ptr = NULL;
-	}
-	if (chunk_ptr) {
-		free_pages_exact(chunk_ptr,
-				 dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
-		chunk_ptr = NULL;
-	}
-}
-__exitcall(ion_dummy_exit);
diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
deleted file mode 100644
index 7791c70..0000000
--- a/drivers/staging/android/ion/ion_of.c
+++ /dev/null
@@ -1,184 +0,0 @@
-/*
- * Based on work from:
- *   Andrew Andrianov <andrew@ncrmnt.org>
- *   Google
- *   The Linux Foundation
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include <linux/init.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include <linux/of.h>
-#include <linux/of_platform.h>
-#include <linux/of_address.h>
-#include <linux/clk.h>
-#include <linux/dma-mapping.h>
-#include <linux/cma.h>
-#include <linux/dma-contiguous.h>
-#include <linux/io.h>
-#include <linux/of_reserved_mem.h>
-#include "ion.h"
-#include "ion_priv.h"
-#include "ion_of.h"
-
-static int ion_parse_dt_heap_common(struct device_node *heap_node,
-				    struct ion_platform_heap *heap,
-				    struct ion_of_heap *compatible)
-{
-	int i;
-
-	for (i = 0; compatible[i].name; i++) {
-		if (of_device_is_compatible(heap_node, compatible[i].compat))
-			break;
-	}
-
-	if (!compatible[i].name)
-		return -ENODEV;
-
-	heap->id = compatible[i].heap_id;
-	heap->type = compatible[i].type;
-	heap->name = compatible[i].name;
-	heap->align = compatible[i].align;
-
-	/* Some kind of callback function pointer? */
-
-	pr_info("%s: id %d type %d name %s align %lx\n", __func__,
-		heap->id, heap->type, heap->name, heap->align);
-	return 0;
-}
-
-static int ion_setup_heap_common(struct platform_device *parent,
-				 struct device_node *heap_node,
-				 struct ion_platform_heap *heap)
-{
-	int ret = 0;
-
-	switch (heap->type) {
-	case ION_HEAP_TYPE_CARVEOUT:
-	case ION_HEAP_TYPE_CHUNK:
-		if (heap->base && heap->size)
-			return 0;
-
-		ret = of_reserved_mem_device_init(heap->priv);
-		break;
-	default:
-		break;
-	}
-
-	return ret;
-}
-
-struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
-				       struct ion_of_heap *compatible)
-{
-	int num_heaps, ret;
-	const struct device_node *dt_node = pdev->dev.of_node;
-	struct device_node *node;
-	struct ion_platform_heap *heaps;
-	struct ion_platform_data *data;
-	int i = 0;
-
-	num_heaps = of_get_available_child_count(dt_node);
-
-	if (!num_heaps)
-		return ERR_PTR(-EINVAL);
-
-	heaps = devm_kzalloc(&pdev->dev,
-			     sizeof(struct ion_platform_heap) * num_heaps,
-			     GFP_KERNEL);
-	if (!heaps)
-		return ERR_PTR(-ENOMEM);
-
-	data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
-			    GFP_KERNEL);
-	if (!data)
-		return ERR_PTR(-ENOMEM);
-
-	for_each_available_child_of_node(dt_node, node) {
-		struct platform_device *heap_pdev;
-
-		ret = ion_parse_dt_heap_common(node, &heaps[i], compatible);
-		if (ret)
-			return ERR_PTR(ret);
-
-		heap_pdev = of_platform_device_create(node, heaps[i].name,
-						      &pdev->dev);
-		if (!heap_pdev)
-			return ERR_PTR(-ENOMEM);
-		heap_pdev->dev.platform_data = &heaps[i];
-
-		heaps[i].priv = &heap_pdev->dev;
-
-		ret = ion_setup_heap_common(pdev, node, &heaps[i]);
-		if (ret)
-			goto out_err;
-		i++;
-	}
-
-	data->heaps = heaps;
-	data->nr = num_heaps;
-	return data;
-
-out_err:
-	for ( ; i >= 0; i--)
-		if (heaps[i].priv)
-			of_device_unregister(to_platform_device(heaps[i].priv));
-
-	return ERR_PTR(ret);
-}
-
-void ion_destroy_platform_data(struct ion_platform_data *data)
-{
-	int i;
-
-	for (i = 0; i < data->nr; i++)
-		if (data->heaps[i].priv)
-			of_device_unregister(to_platform_device(
-				data->heaps[i].priv));
-}
-
-#ifdef CONFIG_OF_RESERVED_MEM
-#include <linux/of.h>
-#include <linux/of_fdt.h>
-#include <linux/of_reserved_mem.h>
-
-static int rmem_ion_device_init(struct reserved_mem *rmem, struct device *dev)
-{
-	struct platform_device *pdev = to_platform_device(dev);
-	struct ion_platform_heap *heap = pdev->dev.platform_data;
-
-	heap->base = rmem->base;
-	heap->base = rmem->size;
-	pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
-		 heap->name, &rmem->base, &rmem->size, dev);
-	return 0;
-}
-
-static void rmem_ion_device_release(struct reserved_mem *rmem,
-				    struct device *dev)
-{
-}
-
-static const struct reserved_mem_ops rmem_dma_ops = {
-	.device_init	= rmem_ion_device_init,
-	.device_release	= rmem_ion_device_release,
-};
-
-static int __init rmem_ion_setup(struct reserved_mem *rmem)
-{
-	phys_addr_t size = rmem->size;
-
-	size = size / 1024;
-
-	pr_info("Ion memory setup at %pa size %pa MiB\n",
-		&rmem->base, &size);
-	rmem->ops = &rmem_dma_ops;
-	return 0;
-}
-
-RESERVEDMEM_OF_DECLARE(ion, "ion-region", rmem_ion_setup);
-#endif
diff --git a/drivers/staging/android/ion/ion_of.h b/drivers/staging/android/ion/ion_of.h
deleted file mode 100644
index 8241a17..0000000
--- a/drivers/staging/android/ion/ion_of.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Based on work from:
- *   Andrew Andrianov <andrew@ncrmnt.org>
- *   Google
- *   The Linux Foundation
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef _ION_OF_H
-#define _ION_OF_H
-
-struct ion_of_heap {
-	const char *compat;
-	int heap_id;
-	int type;
-	const char *name;
-	int align;
-};
-
-#define PLATFORM_HEAP(_compat, _id, _type, _name) \
-{ \
-	.compat = _compat, \
-	.heap_id = _id, \
-	.type = _type, \
-	.name = _name, \
-	.align = PAGE_SIZE, \
-}
-
-struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
-					struct ion_of_heap *compatible);
-
-void ion_destroy_platform_data(struct ion_platform_data *data);
-
-#endif
diff --git a/drivers/staging/android/ion/tegra/Makefile b/drivers/staging/android/ion/tegra/Makefile
deleted file mode 100644
index 808f1f5..0000000
--- a/drivers/staging/android/ion/tegra/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_ION_TEGRA) += tegra_ion.o
diff --git a/drivers/staging/android/ion/tegra/tegra_ion.c b/drivers/staging/android/ion/tegra/tegra_ion.c
deleted file mode 100644
index 49e55e5..0000000
--- a/drivers/staging/android/ion/tegra/tegra_ion.c
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- * drivers/gpu/tegra/tegra_ion.c
- *
- * Copyright (C) 2011 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/err.h>
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/slab.h>
-#include "../ion.h"
-#include "../ion_priv.h"
-
-static struct ion_device *idev;
-static int num_heaps;
-static struct ion_heap **heaps;
-
-static int tegra_ion_probe(struct platform_device *pdev)
-{
-	struct ion_platform_data *pdata = pdev->dev.platform_data;
-	int err;
-	int i;
-
-	num_heaps = pdata->nr;
-
-	heaps = devm_kcalloc(&pdev->dev, pdata->nr,
-			     sizeof(struct ion_heap *), GFP_KERNEL);
-
-	idev = ion_device_create(NULL);
-	if (IS_ERR(idev))
-		return PTR_ERR(idev);
-
-	/* create the heaps as specified in the board file */
-	for (i = 0; i < num_heaps; i++) {
-		struct ion_platform_heap *heap_data = &pdata->heaps[i];
-
-		heaps[i] = ion_heap_create(heap_data);
-		if (IS_ERR_OR_NULL(heaps[i])) {
-			err = PTR_ERR(heaps[i]);
-			goto err;
-		}
-		ion_device_add_heap(idev, heaps[i]);
-	}
-	platform_set_drvdata(pdev, idev);
-	return 0;
-err:
-	for (i = 0; i < num_heaps; ++i)
-		ion_heap_destroy(heaps[i]);
-	return err;
-}
-
-static int tegra_ion_remove(struct platform_device *pdev)
-{
-	struct ion_device *idev = platform_get_drvdata(pdev);
-	int i;
-
-	ion_device_destroy(idev);
-	for (i = 0; i < num_heaps; i++)
-		ion_heap_destroy(heaps[i]);
-	return 0;
-}
-
-static struct platform_driver ion_driver = {
-	.probe = tegra_ion_probe,
-	.remove = tegra_ion_remove,
-	.driver = { .name = "ion-tegra" }
-};
-
-module_platform_driver(ion_driver);
-
-- 
2.7.4

[RFC PATCH 08/12] cma: Store a name in the cma structure

[Laura Abbott]

Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/base/dma-contiguous.c |  5 +++--
 include/linux/cma.h           |  4 +++-
 mm/cma.c                      | 11 +++++++++--
 mm/cma.h                      |  1 +
 mm/cma_debug.c                |  2 +-
 5 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1..4f638ab 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -165,7 +165,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size, phys_addr_t base,
 {
 	int ret;
 
-	ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed, res_cma);
+	ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed,
+					"reserved", res_cma);
 	if (ret)
 		return ret;
 
@@ -257,7 +258,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
 		return -EINVAL;
 	}
 
-	err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
+	err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, &cma);
 	if (err) {
 		pr_err("Reserved memory: unable to setup CMA region\n");
 		return err;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 6f0a91b..49f98ea 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -21,13 +21,15 @@ struct cma;
 extern unsigned long totalcma_pages;
 extern phys_addr_t cma_get_base(const struct cma *cma);
 extern unsigned long cma_get_size(const struct cma *cma);
+extern const char *cma_get_name(const struct cma *cma);
 
 extern int __init cma_declare_contiguous(phys_addr_t base,
 			phys_addr_t size, phys_addr_t limit,
 			phys_addr_t alignment, unsigned int order_per_bit,
-			bool fixed, struct cma **res_cma);
+			bool fixed, const char *name, struct cma **res_cma);
 extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					unsigned int order_per_bit,
+					const char *name,
 					struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
diff --git a/mm/cma.c b/mm/cma.c
index 94b3460..4a93d2b 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -53,6 +53,11 @@ unsigned long cma_get_size(const struct cma *cma)
 	return cma->count << PAGE_SHIFT;
 }
 
+const char *cma_get_name(const struct cma *cma)
+{
+	return cma->name ? cma->name : "(undefined)";
+}
+
 static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
 					     int align_order)
 {
@@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
  */
 int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 				 unsigned int order_per_bit,
+				 const char *name,
 				 struct cma **res_cma)
 {
 	struct cma *cma;
@@ -201,6 +207,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 	cma->base_pfn = PFN_DOWN(base);
 	cma->count = size >> PAGE_SHIFT;
 	cma->order_per_bit = order_per_bit;
+	cma->name = name;
 	*res_cma = cma;
 	cma_area_count++;
 	totalcma_pages += (size / PAGE_SIZE);
@@ -229,7 +236,7 @@ int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 int __init cma_declare_contiguous(phys_addr_t base,
 			phys_addr_t size, phys_addr_t limit,
 			phys_addr_t alignment, unsigned int order_per_bit,
-			bool fixed, struct cma **res_cma)
+			bool fixed, const char *name, struct cma **res_cma)
 {
 	phys_addr_t memblock_end = memblock_end_of_DRAM();
 	phys_addr_t highmem_start;
@@ -335,7 +342,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
 		base = addr;
 	}
 
-	ret = cma_init_reserved_mem(base, size, order_per_bit, res_cma);
+	ret = cma_init_reserved_mem(base, size, order_per_bit, name, res_cma);
 	if (ret)
 		goto err;
 
diff --git a/mm/cma.h b/mm/cma.h
index 17c75a4..4986128 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -11,6 +11,7 @@ struct cma {
 	struct hlist_head mem_head;
 	spinlock_t mem_head_lock;
 #endif
+	const char *name;
 };
 
 extern struct cma cma_areas[MAX_CMA_AREAS];
diff --git a/mm/cma_debug.c b/mm/cma_debug.c
index f8e4b60..4742efd 100644
--- a/mm/cma_debug.c
+++ b/mm/cma_debug.c
@@ -167,7 +167,7 @@ static void cma_debugfs_add_one(struct cma *cma, int idx)
 	char name[16];
 	int u32s;
 
-	sprintf(name, "cma-%d", idx);
+	sprintf(name, "cma-%s", cma->name);
 
 	tmp = debugfs_create_dir(name, cma_debugfs_root);
 
-- 
2.7.4

[RFC PATCH 09/12] cma: Introduce cma_for_each_area

[Laura Abbott]

Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 include/linux/cma.h |  2 ++
 mm/cma.c            | 14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index 49f98ea..b521e3c 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -33,4 +33,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
 					struct cma **res_cma);
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
 extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);
 #endif
diff --git a/mm/cma.c b/mm/cma.c
index 4a93d2b..a430df0 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,3 +464,17 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
 
 	return true;
 }
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+	int i;
+
+	for (i = 0; i < cma_area_count; i++) {
+		int ret = it(&cma_areas[i], data);
+
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
-- 
2.7.4

[RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also avoids awkward
caching questions.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/ion_cma_heap.c | 97 ++++++++----------------------
 1 file changed, 26 insertions(+), 71 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..6838825 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include <linux/slab.h>
 #include <linux/errno.h>
 #include <linux/err.h>
-#include <linux/dma-mapping.h>
+#include <linux/cma.h>
+#include <linux/scatterlist.h>
 
 #include "ion.h"
 #include "ion_priv.h"
 
 struct ion_cma_heap {
 	struct ion_heap heap;
-	struct device *dev;
+	struct cma *cma;
 };
 
 #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
 
-struct ion_cma_buffer_info {
-	void *cpu_addr;
-	dma_addr_t handle;
-	struct sg_table *table;
-};
-
 
 /* ION CMA heap operations functions */
 static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
 			    unsigned long flags)
 {
 	struct ion_cma_heap *cma_heap = to_cma_heap(heap);
-	struct device *dev = cma_heap->dev;
-	struct ion_cma_buffer_info *info;
-
-	dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
-	if (buffer->flags & ION_FLAG_CACHED)
-		return -EINVAL;
+	struct sg_table *table;
+	struct page *pages;
+	int ret;
 
-	info = kzalloc(sizeof(*info), GFP_KERNEL);
-	if (!info)
+	pages = cma_alloc(cma_heap->cma, len, 0);
+	if (!pages)
 		return -ENOMEM;
 
-	info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
-						GFP_HIGHUSER | __GFP_ZERO);
-
-	if (!info->cpu_addr) {
-		dev_err(dev, "Fail to allocate buffer\n");
+	table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+	if (!table)
 		goto err;
-	}
 
-	info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
-	if (!info->table)
+	ret = sg_alloc_table(table, 1, GFP_KERNEL);
+	if (ret)
 		goto free_mem;
 
-	if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
-			    len))
-		goto free_table;
-	/* keep this for memory release */
-	buffer->priv_virt = info;
-	buffer->sg_table = info->table;
-	dev_dbg(dev, "Allocate buffer %p\n", buffer);
+	sg_set_page(table->sgl, pages, len, 0);
+
+	buffer->priv_virt = pages;
+	buffer->sg_table = table;
 	return 0;
 
-free_table:
-	kfree(info->table);
 free_mem:
-	dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+	kfree(table);
 err:
-	kfree(info);
+	cma_release(cma_heap->cma, pages, buffer->size);
 	return -ENOMEM;
 }
 
 static void ion_cma_free(struct ion_buffer *buffer)
 {
 	struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
-	struct device *dev = cma_heap->dev;
-	struct ion_cma_buffer_info *info = buffer->priv_virt;
+	struct page *pages = buffer->priv_virt;
 
-	dev_dbg(dev, "Release buffer %p\n", buffer);
 	/* release memory */
-	dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
+	cma_release(cma_heap->cma, pages, buffer->size);
 	/* release sg table */
-	sg_free_table(info->table);
-	kfree(info->table);
-	kfree(info);
-}
-
-static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
-			struct vm_area_struct *vma)
-{
-	struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
-	struct device *dev = cma_heap->dev;
-	struct ion_cma_buffer_info *info = buffer->priv_virt;
-
-	return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
-				 buffer->size);
-}
-
-static void *ion_cma_map_kernel(struct ion_heap *heap,
-				struct ion_buffer *buffer)
-{
-	struct ion_cma_buffer_info *info = buffer->priv_virt;
-	/* kernel memory mapping has been done at allocation time */
-	return info->cpu_addr;
-}
-
-static void ion_cma_unmap_kernel(struct ion_heap *heap,
-				 struct ion_buffer *buffer)
-{
+	sg_free_table(buffer->sg_table);
+	kfree(buffer->sg_table);
 }
 
 static struct ion_heap_ops ion_cma_ops = {
 	.allocate = ion_cma_allocate,
 	.free = ion_cma_free,
-	.map_user = ion_cma_mmap,
-	.map_kernel = ion_cma_map_kernel,
-	.unmap_kernel = ion_cma_unmap_kernel,
+	.map_user = ion_heap_map_user,
+	.map_kernel = ion_heap_map_kernel,
+	.unmap_kernel = ion_heap_unmap_kernel,
 };
 
 struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
@@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
 	 * get device from private heaps data, later it will be
 	 * used to make the link with reserved CMA memory
 	 */
-	cma_heap->dev = data->priv;
+	cma_heap->cma = data->priv;
 	cma_heap->heap.type = ION_HEAP_TYPE_DMA;
 	return &cma_heap->heap;
 }
-- 
2.7.4

[RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

[Laura Abbott]

Currently, all heaps are compiled in all the time. In switching to
a better platform model, let's allow these to be compiled out for good
measure.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/Kconfig    | 32 ++++++++++++++++++++
 drivers/staging/android/ion/Makefile   |  8 +++--
 drivers/staging/android/ion/ion_priv.h | 53 ++++++++++++++++++++++++++++++++--
 3 files changed, 87 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index 0c91b2b..2e97990 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,3 +17,35 @@ config ION_TEST
 	  Choose this option to create a device that can be used to test the
 	  kernel and device side ION functions.
 
+config ION_SYSTEM_HEAP
+	bool "Ion system heap"
+	depends on ION
+	help
+	  Choose this option to enable the Ion system heap. The system heap
+	  is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+	bool "Ion carveout heap support"
+	depends on ION
+	help
+	  Choose this option to enable carveout heaps with Ion. Carveout heaps
+	  are backed by memory reserved from the system. Allocation times are
+	  typically faster at the cost of memory not being used. Unless you
+	  know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+	bool "Ion chunk heap support"
+	depends on ION
+	help
+          Choose this option to enable chunk heaps with Ion. This heap is
+	  similar in function the carveout heap but memory is broken down
+	  into smaller chunk sizes, typically corresponding to a TLB size.
+	  Unless you know your system has these regions, you should say N here.
+
+config ION_CMA_HEAP
+	bool "Ion CMA heap support"
+	depends on ION && CMA
+	help
+	  Choose this option to enable CMA heaps with Ion. This heap is backed
+	  by the Contiguous Memory Allocator (CMA). If your system has these
+	  regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index 9457090..eef022b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,8 @@
-obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o \
-			ion_page_pool.o ion_system_heap.o \
-			ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 obj-$(CONFIG_ION_TEST) += ion_test.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index b09bc7c..6eafe0d 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
  * heaps as appropriate.
  */
 
+
 struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
 void ion_heap_destroy(struct ion_heap *heap);
+
+#ifdef CONFIG_ION_SYSTEM_HEAP
 struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
 void ion_system_heap_destroy(struct ion_heap *heap);
-
 struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *heap);
 void ion_system_contig_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap * ion_system_heap_create(
+	struct ion_platform_heap *unused)
+{
+	return ERR_PTR(-ENODEV);
+}
+static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
+
+static inline struct ion_heap *ion_system_contig_heap_create(
+	struct ion_platform_heap *heap)
+{
+	return ERR_PTR(-ENODEV);
+}
+
+static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CARVEOUT_HEAP
 struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
 void ion_carveout_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap *ion_carveout_heap_create(
+	struct ion_platform_heap *heap_data)
+{
+	return ERR_PTR(-ENODEV);
+}
+static inline void ion_carveout_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CHUNK_HEAP
 struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
 void ion_chunk_heap_destroy(struct ion_heap *heap);
+#else
+static inline struct ion_heap *ion_chunk_heap_create(
+	struct ion_platform_heap *heap_data)
+{
+	return ERR_PTR(-ENODEV);
+}
+static inline void ion_chunk_heap_destroy(struct ion_heap *heap) { }
+
+#endif
+
+#ifdef CONFIG_ION_CMA_HEAP
 struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
 void ion_cma_heap_destroy(struct ion_heap *heap);
+#else
+static inline struct ion_heap *ion_cma_heap_create(
+	struct ion_platform_heap *data)
+{
+	return ERR_PTR(-ENODEV);
+}
+static inline void ion_cma_heap_destroy(struct ion_heap *heap) { }
+#endif
 
 /**
  * functions for creating and destroying a heap pool -- allows you
-- 
2.7.4

[RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps

[Laura Abbott]

Practiaclly speaking, most Ion heaps are either going to be available
all the time (system heaps) or found based off of the reserved-memory
node. Parse the CMA and reserved-memory nodes to assign the heaps.

Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 drivers/staging/android/ion/Makefile        |  2 +-
 drivers/staging/android/ion/ion_enumerate.c | 89 +++++++++++++++++++++++++++++
 2 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/android/ion/ion_enumerate.c

diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index eef022b..4ebf655 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o ion_enumerate.o
 obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
 obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
 obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
diff --git a/drivers/staging/android/ion/ion_enumerate.c b/drivers/staging/android/ion/ion_enumerate.c
new file mode 100644
index 0000000..21344c7
--- /dev/null
+++ b/drivers/staging/android/ion/ion_enumerate.c
@@ -0,0 +1,89 @@
+#include <linux/kernel.h>
+#include <linux/cma.h>
+
+#include "ion.h"
+#include "ion_priv.h"
+
+static struct ion_device *internal_dev;
+static int heap_id = 2;
+
+static int ion_add_system_heap(void)
+{
+#ifdef CONFIG_ION_SYSTEM_HEAP
+	struct ion_platform_heap pheap;
+	struct ion_heap *heap;
+
+	pheap.type = ION_HEAP_TYPE_SYSTEM;
+	pheap.id = heap_id++;
+	pheap.name = "ion_system_heap";
+
+	heap = ion_heap_create(&pheap);
+	if (!heap)
+		return -ENODEV;
+
+	ion_device_add_heap(internal_dev, heap);
+#endif
+	return 0;
+}
+
+static int ion_add_system_contig_heap(void)
+{
+#ifdef CONFIG_ION_SYSTEM_HEAP
+	struct ion_platform_heap pheap;
+	struct ion_heap *heap;
+
+	pheap.type = ION_HEAP_TYPE_SYSTEM_CONTIG;
+	pheap.id = heap_id++;
+	pheap.name = "ion_system_contig_heap";
+
+	heap = ion_heap_create(&pheap);
+	if (!heap)
+		return -ENODEV;
+
+	ion_device_add_heap(internal_dev, heap);
+#endif
+	return 0;
+}
+
+#ifdef CONFIG_ION_CMA_HEAP
+int __ion_add_cma_heaps(struct cma *cma, void *data)
+{
+	struct ion_heap *heap;
+	struct ion_platform_heap pheap;
+
+	pheap.type = ION_HEAP_TYPE_DMA;
+	pheap.id = heap_id++;
+	pheap.name = cma_get_name(cma);
+	pheap.priv = cma;
+
+	heap = ion_heap_create(&pheap);
+	if (!heap)
+		return -ENODEV;
+
+	ion_device_add_heap(internal_dev, heap);
+	return 0;
+}
+#endif
+
+
+static int ion_add_cma_heaps(void)
+{
+#ifdef CONFIG_ION_CMA_HEAP
+	cma_for_each_area(__ion_add_cma_heaps, NULL);
+#endif
+	return 0;
+}
+
+int ion_enumerate(void)
+{
+	internal_dev = ion_device_create(NULL);
+	if (IS_ERR(internal_dev))
+		return PTR_ERR(internal_dev);
+
+	ion_add_system_heap();
+	ion_add_system_contig_heap();
+
+	ion_add_cma_heaps();
+	return 0;
+}
+subsys_initcall(ion_enumerate);
-- 
2.7.4

Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Hillf Danton]

On March 03, 2017 5:45 AM Laura Abbott wrote: 
> 
> +static struct sg_table *dup_sg_table(struct sg_table *table)
> +{
> +	struct sg_table *new_table;
> +	int ret, i;
> +	struct scatterlist *sg, *new_sg;
> +
> +	new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
> +	if (!new_table)
> +		return ERR_PTR(-ENOMEM);
> +
> +	ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
> +	if (ret) {
> +		kfree(table);

Free new table?

> +		return ERR_PTR(-ENOMEM);
> +	}
> +
> +	new_sg = new_table->sgl;
> +	for_each_sg(table->sgl, sg, table->nents, i) {
> +		memcpy(new_sg, sg, sizeof(*sg));
> +		sg->dma_address = 0;
> +		new_sg = sg_next(new_sg);
> +	}
> +

Do we need a helper, sg_copy_table(dst_table, src_table)?

> +	return new_table;
> +}
> +

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> 
> 
> Now that we call dma_map in the dma_buf API callbacks there is no need
> to use the existing cache APIs. Remove the sync ioctl and the existing
> bad dma_sync calls. Explicit caching can be handled with the dma_buf
> sync API.
> 
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
>  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
>  drivers/staging/android/ion/ion.c               | 40 -------------------------
>  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
>  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
>  drivers/staging/android/ion/ion_page_pool.c     |  3 --
>  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
>  6 files changed, 65 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
> index 5b2e93f..f820d77 100644
> --- a/drivers/staging/android/ion/ion-ioctl.c
> +++ b/drivers/staging/android/ion/ion-ioctl.c
> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>  			data.handle.handle = handle->id;
>  		break;
>  	}
> -	case ION_IOC_SYNC:
> -	{
> -		ret = ion_sync_for_device(client, data.fd.fd);
> -		break;
> -	}

You missed the case ION_IOC_SYNC: in compat_ion.c.

While at it: Should we also remove the entire custom_ioctl infrastructure?
It's entirely unused afaict, and for a pure buffer allocator I don't see
any need to have custom ioctl.

More code to remove potentially:
- The entire compat ioctl stuff - would be an abi break, but I guess if we
  pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
  would allow us to remove compat_ion.c entirely.

- ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
  still need to be able to import anything. All the cache flushing/mapping
  is done through dma-buf ops/ioctls.


With the case in compat_ion.c also removed, this patch is:

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

>  	case ION_IOC_CUSTOM:
>  	{
>  		if (!dev->custom_ioctl)
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index 8eef1d7..c3c316f 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>  	free_duped_table(table);
>  }
>  
> -void ion_pages_sync_for_device(struct device *dev, struct page *page,
> -			       size_t size, enum dma_data_direction dir)
> -{
> -	struct scatterlist sg;
> -
> -	sg_init_table(&sg, 1);
> -	sg_set_page(&sg, page, size, 0);
> -	/*
> -	 * This is not correct - sg_dma_address needs a dma_addr_t that is valid
> -	 * for the targeted device, but this works on the currently targeted
> -	 * hardware.
> -	 */
> -	sg_dma_address(&sg) = page_to_phys(page);
> -	dma_sync_sg_for_device(dev, &sg, 1, dir);
> -}
> -
>  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>  {
>  	struct ion_buffer *buffer = dmabuf->priv;
> @@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
>  }
>  EXPORT_SYMBOL(ion_import_dma_buf_fd);
>  
> -int ion_sync_for_device(struct ion_client *client, int fd)
> -{
> -	struct dma_buf *dmabuf;
> -	struct ion_buffer *buffer;
> -
> -	dmabuf = dma_buf_get(fd);
> -	if (IS_ERR(dmabuf))
> -		return PTR_ERR(dmabuf);
> -
> -	/* if this memory came from ion */
> -	if (dmabuf->ops != &dma_buf_ops) {
> -		pr_err("%s: can not sync dmabuf from another exporter\n",
> -		       __func__);
> -		dma_buf_put(dmabuf);
> -		return -EINVAL;
> -	}
> -	buffer = dmabuf->priv;
> -
> -	dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
> -			       buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> -	dma_buf_put(dmabuf);
> -	return 0;
> -}
> -
>  int ion_query_heaps(struct ion_client *client, struct ion_heap_query *query)
>  {
>  	struct ion_device *dev = client->dev;
> diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c
> index 9bf8e98..e0e360f 100644
> --- a/drivers/staging/android/ion/ion_carveout_heap.c
> +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
>  
>  	ion_heap_buffer_zero(buffer);
>  
> -	if (ion_buffer_cached(buffer))
> -		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> -				       DMA_BIDIRECTIONAL);
> -
>  	ion_carveout_free(heap, paddr, buffer->size);
>  	sg_free_table(table);
>  	kfree(table);
> @@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data)
>  	page = pfn_to_page(PFN_DOWN(heap_data->base));
>  	size = heap_data->size;
>  
> -	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> -
>  	ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
>  	if (ret)
>  		return ERR_PTR(ret);
> diff --git a/drivers/staging/android/ion/ion_chunk_heap.c b/drivers/staging/android/ion/ion_chunk_heap.c
> index 8c41889..46e13f6 100644
> --- a/drivers/staging/android/ion/ion_chunk_heap.c
> +++ b/drivers/staging/android/ion/ion_chunk_heap.c
> @@ -101,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer *buffer)
>  
>  	ion_heap_buffer_zero(buffer);
>  
> -	if (ion_buffer_cached(buffer))
> -		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> -				       DMA_BIDIRECTIONAL);
> -
>  	for_each_sg(table->sgl, sg, table->nents, i) {
>  		gen_pool_free(chunk_heap->pool, page_to_phys(sg_page(sg)),
>  			      sg->length);
> @@ -132,8 +128,6 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
>  	page = pfn_to_page(PFN_DOWN(heap_data->base));
>  	size = heap_data->size;
>  
> -	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> -
>  	ret = ion_heap_pages_zero(page, size, pgprot_writecombine(PAGE_KERNEL));
>  	if (ret)
>  		return ERR_PTR(ret);
> diff --git a/drivers/staging/android/ion/ion_page_pool.c b/drivers/staging/android/ion/ion_page_pool.c
> index aea89c1..532eda7 100644
> --- a/drivers/staging/android/ion/ion_page_pool.c
> +++ b/drivers/staging/android/ion/ion_page_pool.c
> @@ -30,9 +30,6 @@ static void *ion_page_pool_alloc_pages(struct ion_page_pool *pool)
>  
>  	if (!page)
>  		return NULL;
> -	if (!pool->cached)
> -		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool->order,
> -					  DMA_BIDIRECTIONAL);
>  	return page;
>  }
>  
> diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
> index 6cb2fe7..a33331b 100644
> --- a/drivers/staging/android/ion/ion_system_heap.c
> +++ b/drivers/staging/android/ion/ion_system_heap.c
> @@ -75,9 +75,6 @@ static struct page *alloc_buffer_page(struct ion_system_heap *heap,
>  
>  	page = ion_page_pool_alloc(pool);
>  
> -	if (cached)
> -		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
> -					  DMA_BIDIRECTIONAL);
>  	return page;
>  }
>  
> @@ -401,8 +398,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
>  
>  	buffer->sg_table = table;
>  
> -	ion_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
> -
>  	return 0;
>  
>  free_table:
> -- 
> 2.7.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.
> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.
> 
> Feedback appreciated.

Imo looks all good. And I just realized that cross-checking with the TODO,
the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.

Otherwise I looked through the patches, looks all really reasonable.

Wrt merging, my experience from destaging the android syncpt stuff was
that merging the patches through the staging tree lead to lots of
cross-tree issues with the gpu folks wanting to use that. Ion will
probably run into similar things, so I'd propose we pull these cleanup
patches and the eventual de-staging in throught drm. Yes that defacto
means I'm also volunteering myself a bit :-)

In the end we could put it all into drivers/gpu/ion or something like
that.

Thoughts? Greg?
-Daniel


> 
> Thanks,
> Laura
> 
> [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> 
> Laura Abbott (12):
>   staging: android: ion: Remove dmap_cnt
>   staging: android: ion: Remove alignment from allocation field
>   staging: android: ion: Duplicate sg_table
>   staging: android: ion: Call dma_map_sg for syncing and mapping
>   staging: android: ion: Remove page faulting support
>   staging: android: ion: Remove crufty cache support
>   staging: android: ion: Remove old platform support
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Make Ion heaps selectable
>   staging; android: ion: Enumerate all available heaps
> 
>  drivers/base/dma-contiguous.c                      |   5 +-
>  drivers/staging/android/ion/Kconfig                |  51 ++--
>  drivers/staging/android/ion/Makefile               |  14 +-
>  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
>  drivers/staging/android/ion/ion-ioctl.c            |   6 -
>  drivers/staging/android/ion/ion.c                  | 282 ++++++---------------
>  drivers/staging/android/ion/ion.h                  |   5 +-
>  drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
>  drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
>  drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
>  drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
>  drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
>  drivers/staging/android/ion/ion_of.c               | 184 --------------
>  drivers/staging/android/ion/ion_of.h               |  37 ---
>  drivers/staging/android/ion/ion_page_pool.c        |   3 -
>  drivers/staging/android/ion/ion_priv.h             |  57 ++++-
>  drivers/staging/android/ion/ion_system_heap.c      |  14 +-
>  drivers/staging/android/ion/tegra/Makefile         |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
>  include/linux/cma.h                                |   6 +-
>  mm/cma.c                                           |  25 +-
>  mm/cma.h                                           |   1 +
>  mm/cma_debug.c                                     |   2 +-
>  25 files changed, 312 insertions(+), 958 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
> 
> -- 
> 2.7.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> > 
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
> > This series does what should be the final clean ups for it to possibly be
> > moved out of staging.
> > 
> > This includes the following:
> > - Some general clean up and removal of features that never got a lot of use
> >   as far as I can tell.
> > - Fixing up the caching. This is the series I proposed back in December[2]
> >   but never heard any feedback on. It will certainly break existing
> >   applications that rely on the implicit caching. I'd rather make an effort
> >   to move to a model that isn't going directly against the establishement
> >   though.
> > - Fixing up the platform support. The devicetree approach was never well
> >   recieved by DT maintainers. The proposal here is to think of Ion less as
> >   specifying requirements and more of a framework for exposing memory to
> >   userspace.
> > - CMA allocations now happen without the need of a dummy device structure.
> >   This fixes a bunch of the reasons why I attempted to add devicetree
> >   support before.
> > 
> > I've had problems getting feedback in the past so if I don't hear any major
> > objections I'm going to send out with the RFC dropped to be picked up.
> > The only reason there isn't a patch to come out of staging is to discuss any
> > other changes to the ABI people might want. Once this comes out of staging,
> > I really don't want to mess with the ABI.
> > 
> > Feedback appreciated.
> 
> Imo looks all good. And I just realized that cross-checking with the TODO,
> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.

One more for the todo: Add rst/sphinx documentation for ION. That's also
always a good excuse to review the internal interfaces and exported
symbols. But we can do that after destaging ...
-Daniel

> 
> Otherwise I looked through the patches, looks all really reasonable.
> 
> Wrt merging, my experience from destaging the android syncpt stuff was
> that merging the patches through the staging tree lead to lots of
> cross-tree issues with the gpu folks wanting to use that. Ion will
> probably run into similar things, so I'd propose we pull these cleanup
> patches and the eventual de-staging in throught drm. Yes that defacto
> means I'm also volunteering myself a bit :-)
> 
> In the end we could put it all into drivers/gpu/ion or something like
> that.
> 
> Thoughts? Greg?
> -Daniel
> 
> 
> > 
> > Thanks,
> > Laura
> > 
> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> > 
> > Laura Abbott (12):
> >   staging: android: ion: Remove dmap_cnt
> >   staging: android: ion: Remove alignment from allocation field
> >   staging: android: ion: Duplicate sg_table
> >   staging: android: ion: Call dma_map_sg for syncing and mapping
> >   staging: android: ion: Remove page faulting support
> >   staging: android: ion: Remove crufty cache support
> >   staging: android: ion: Remove old platform support
> >   cma: Store a name in the cma structure
> >   cma: Introduce cma_for_each_area
> >   staging: android: ion: Use CMA APIs directly
> >   staging: android: ion: Make Ion heaps selectable
> >   staging; android: ion: Enumerate all available heaps
> > 
> >  drivers/base/dma-contiguous.c                      |   5 +-
> >  drivers/staging/android/ion/Kconfig                |  51 ++--
> >  drivers/staging/android/ion/Makefile               |  14 +-
> >  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
> >  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
> >  drivers/staging/android/ion/ion-ioctl.c            |   6 -
> >  drivers/staging/android/ion/ion.c                  | 282 ++++++---------------
> >  drivers/staging/android/ion/ion.h                  |   5 +-
> >  drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
> >  drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
> >  drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
> >  drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
> >  drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
> >  drivers/staging/android/ion/ion_of.c               | 184 --------------
> >  drivers/staging/android/ion/ion_of.h               |  37 ---
> >  drivers/staging/android/ion/ion_page_pool.c        |   3 -
> >  drivers/staging/android/ion/ion_priv.h             |  57 ++++-
> >  drivers/staging/android/ion/ion_system_heap.c      |  14 +-
> >  drivers/staging/android/ion/tegra/Makefile         |   1 -
> >  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
> >  include/linux/cma.h                                |   6 +-
> >  mm/cma.c                                           |  25 +-
> >  mm/cma.h                                           |   1 +
> >  mm/cma_debug.c                                     |   2 +-
> >  25 files changed, 312 insertions(+), 958 deletions(-)
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
> >  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
> >  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.h
> >  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
> >  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
> > 
> > -- 
> > 2.7.4
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majordomo@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 07/12] staging: android: ion: Remove old platform support

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:39PM -0800, Laura Abbott wrote:
> 
> Device specific platform support has been haphazard for Ion. There have
> been several independent attempts and there are still objections to
> what bindings exist right now. Just remove everything for a fresh start.
> 
> Signed-off-by: Laura Abbott <labbott@redhat.com>

It looks like with this we could remove a lot of the EXPORT_SYMBOL
statements from the ion code. Might be good to follow up with a patch to
clean those out.

Otherwise a patch that only removes code, what's not to love!

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

> ---
>  drivers/staging/android/ion/Kconfig                |  35 ----
>  drivers/staging/android/ion/Makefile               |   6 -
>  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 -------------
>  drivers/staging/android/ion/ion_dummy_driver.c     | 156 -----------------
>  drivers/staging/android/ion/ion_of.c               | 184 ---------------------
>  drivers/staging/android/ion/ion_of.h               |  37 -----
>  drivers/staging/android/ion/tegra/Makefile         |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ---------
>  10 files changed, 618 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
> 
> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
> index c8fb413..0c91b2b 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -17,38 +17,3 @@ config ION_TEST
>  	  Choose this option to create a device that can be used to test the
>  	  kernel and device side ION functions.
>  
> -config ION_DUMMY
> -	bool "Dummy Ion driver"
> -	depends on ION
> -	help
> -	  Provides a dummy ION driver that registers the
> -	  /dev/ion device and some basic heaps. This can
> -	  be used for testing the ION infrastructure if
> -	  one doesn't have access to hardware drivers that
> -	  use ION.
> -
> -config ION_TEGRA
> -	tristate "Ion for Tegra"
> -	depends on ARCH_TEGRA && ION
> -	help
> -	  Choose this option if you wish to use ion on an nVidia Tegra.
> -
> -config ION_HISI
> -	tristate "Ion for Hisilicon"
> -	depends on ARCH_HISI && ION
> -	select ION_OF
> -	help
> -	  Choose this option if you wish to use ion on Hisilicon Platform.
> -
> -source "drivers/staging/android/ion/hisilicon/Kconfig"
> -
> -config ION_OF
> -	bool "Devicetree support for Ion"
> -	depends on ION && OF_ADDRESS
> -	help
> -	  Provides base support for defining Ion heaps in devicetree
> -	  and setting them up. Also includes functions for platforms
> -	  to parse the devicetree and expand for their own custom
> -	  extensions
> -
> -	  If using Ion and devicetree, you should say Y here
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index 5d630a0..9457090 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -5,9 +5,3 @@ obj-$(CONFIG_ION_TEST) += ion_test.o
>  ifdef CONFIG_COMPAT
>  obj-$(CONFIG_ION) += compat_ion.o
>  endif
> -
> -obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
> -obj-$(CONFIG_ION_TEGRA) += tegra/
> -obj-$(CONFIG_ION_HISI) += hisilicon/
> -obj-$(CONFIG_ION_OF) += ion_of.o
> -
> diff --git a/drivers/staging/android/ion/hisilicon/Kconfig b/drivers/staging/android/ion/hisilicon/Kconfig
> deleted file mode 100644
> index 2b4bd07..0000000
> --- a/drivers/staging/android/ion/hisilicon/Kconfig
> +++ /dev/null
> @@ -1,5 +0,0 @@
> -config HI6220_ION
> -        bool "Hi6220 ION Driver"
> -        depends on ARCH_HISI && ION
> -        help
> -          Build the Hisilicon Hi6220 ion driver.
> diff --git a/drivers/staging/android/ion/hisilicon/Makefile b/drivers/staging/android/ion/hisilicon/Makefile
> deleted file mode 100644
> index 2a89414..0000000
> --- a/drivers/staging/android/ion/hisilicon/Makefile
> +++ /dev/null
> @@ -1 +0,0 @@
> -obj-$(CONFIG_HI6220_ION) += hi6220_ion.o
> diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> deleted file mode 100644
> index 0de7897..0000000
> --- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
> +++ /dev/null
> @@ -1,113 +0,0 @@
> -/*
> - * Hisilicon Hi6220 ION Driver
> - *
> - * Copyright (c) 2015 Hisilicon Limited.
> - *
> - * Author: Chen Feng <puck.chen@hisilicon.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#define pr_fmt(fmt) "Ion: " fmt
> -
> -#include <linux/err.h>
> -#include <linux/platform_device.h>
> -#include <linux/slab.h>
> -#include <linux/of.h>
> -#include <linux/mm.h>
> -#include "../ion_priv.h"
> -#include "../ion.h"
> -#include "../ion_of.h"
> -
> -struct hisi_ion_dev {
> -	struct ion_heap	**heaps;
> -	struct ion_device *idev;
> -	struct ion_platform_data *data;
> -};
> -
> -static struct ion_of_heap hisi_heaps[] = {
> -	PLATFORM_HEAP("hisilicon,sys_user", 0,
> -		      ION_HEAP_TYPE_SYSTEM, "sys_user"),
> -	PLATFORM_HEAP("hisilicon,sys_contig", 1,
> -		      ION_HEAP_TYPE_SYSTEM_CONTIG, "sys_contig"),
> -	PLATFORM_HEAP("hisilicon,cma", ION_HEAP_TYPE_DMA, ION_HEAP_TYPE_DMA,
> -		      "cma"),
> -	{}
> -};
> -
> -static int hi6220_ion_probe(struct platform_device *pdev)
> -{
> -	struct hisi_ion_dev *ipdev;
> -	int i;
> -
> -	ipdev = devm_kzalloc(&pdev->dev, sizeof(*ipdev), GFP_KERNEL);
> -	if (!ipdev)
> -		return -ENOMEM;
> -
> -	platform_set_drvdata(pdev, ipdev);
> -
> -	ipdev->idev = ion_device_create(NULL);
> -	if (IS_ERR(ipdev->idev))
> -		return PTR_ERR(ipdev->idev);
> -
> -	ipdev->data = ion_parse_dt(pdev, hisi_heaps);
> -	if (IS_ERR(ipdev->data))
> -		return PTR_ERR(ipdev->data);
> -
> -	ipdev->heaps = devm_kzalloc(&pdev->dev,
> -				sizeof(struct ion_heap) * ipdev->data->nr,
> -				GFP_KERNEL);
> -	if (!ipdev->heaps) {
> -		ion_destroy_platform_data(ipdev->data);
> -		return -ENOMEM;
> -	}
> -
> -	for (i = 0; i < ipdev->data->nr; i++) {
> -		ipdev->heaps[i] = ion_heap_create(&ipdev->data->heaps[i]);
> -		if (!ipdev->heaps) {
> -			ion_destroy_platform_data(ipdev->data);
> -			return -ENOMEM;
> -		}
> -		ion_device_add_heap(ipdev->idev, ipdev->heaps[i]);
> -	}
> -	return 0;
> -}
> -
> -static int hi6220_ion_remove(struct platform_device *pdev)
> -{
> -	struct hisi_ion_dev *ipdev;
> -	int i;
> -
> -	ipdev = platform_get_drvdata(pdev);
> -
> -	for (i = 0; i < ipdev->data->nr; i++)
> -		ion_heap_destroy(ipdev->heaps[i]);
> -
> -	ion_destroy_platform_data(ipdev->data);
> -	ion_device_destroy(ipdev->idev);
> -
> -	return 0;
> -}
> -
> -static const struct of_device_id hi6220_ion_match_table[] = {
> -	{.compatible = "hisilicon,hi6220-ion"},
> -	{},
> -};
> -
> -static struct platform_driver hi6220_ion_driver = {
> -	.probe = hi6220_ion_probe,
> -	.remove = hi6220_ion_remove,
> -	.driver = {
> -		.name = "ion-hi6220",
> -		.of_match_table = hi6220_ion_match_table,
> -	},
> -};
> -
> -static int __init hi6220_ion_init(void)
> -{
> -	return platform_driver_register(&hi6220_ion_driver);
> -}
> -
> -subsys_initcall(hi6220_ion_init);
> diff --git a/drivers/staging/android/ion/ion_dummy_driver.c b/drivers/staging/android/ion/ion_dummy_driver.c
> deleted file mode 100644
> index cf5c010..0000000
> --- a/drivers/staging/android/ion/ion_dummy_driver.c
> +++ /dev/null
> @@ -1,156 +0,0 @@
> -/*
> - * drivers/gpu/ion/ion_dummy_driver.c
> - *
> - * Copyright (C) 2013 Linaro, Inc
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#include <linux/err.h>
> -#include <linux/platform_device.h>
> -#include <linux/slab.h>
> -#include <linux/init.h>
> -#include <linux/bootmem.h>
> -#include <linux/memblock.h>
> -#include <linux/sizes.h>
> -#include <linux/io.h>
> -#include "ion.h"
> -#include "ion_priv.h"
> -
> -static struct ion_device *idev;
> -static struct ion_heap **heaps;
> -
> -static void *carveout_ptr;
> -static void *chunk_ptr;
> -
> -static struct ion_platform_heap dummy_heaps[] = {
> -		{
> -			.id	= ION_HEAP_TYPE_SYSTEM,
> -			.type	= ION_HEAP_TYPE_SYSTEM,
> -			.name	= "system",
> -		},
> -		{
> -			.id	= ION_HEAP_TYPE_SYSTEM_CONTIG,
> -			.type	= ION_HEAP_TYPE_SYSTEM_CONTIG,
> -			.name	= "system contig",
> -		},
> -		{
> -			.id	= ION_HEAP_TYPE_CARVEOUT,
> -			.type	= ION_HEAP_TYPE_CARVEOUT,
> -			.name	= "carveout",
> -			.size	= SZ_4M,
> -		},
> -		{
> -			.id	= ION_HEAP_TYPE_CHUNK,
> -			.type	= ION_HEAP_TYPE_CHUNK,
> -			.name	= "chunk",
> -			.size	= SZ_4M,
> -			.align	= SZ_16K,
> -			.priv	= (void *)(SZ_16K),
> -		},
> -};
> -
> -static const struct ion_platform_data dummy_ion_pdata = {
> -	.nr = ARRAY_SIZE(dummy_heaps),
> -	.heaps = dummy_heaps,
> -};
> -
> -static int __init ion_dummy_init(void)
> -{
> -	int i, err;
> -
> -	idev = ion_device_create(NULL);
> -	if (IS_ERR(idev))
> -		return PTR_ERR(idev);
> -	heaps = kcalloc(dummy_ion_pdata.nr, sizeof(struct ion_heap *),
> -			GFP_KERNEL);
> -	if (!heaps)
> -		return -ENOMEM;
> -
> -
> -	/* Allocate a dummy carveout heap */
> -	carveout_ptr = alloc_pages_exact(
> -				dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size,
> -				GFP_KERNEL);
> -	if (carveout_ptr)
> -		dummy_heaps[ION_HEAP_TYPE_CARVEOUT].base =
> -						virt_to_phys(carveout_ptr);
> -	else
> -		pr_err("ion_dummy: Could not allocate carveout\n");
> -
> -	/* Allocate a dummy chunk heap */
> -	chunk_ptr = alloc_pages_exact(
> -				dummy_heaps[ION_HEAP_TYPE_CHUNK].size,
> -				GFP_KERNEL);
> -	if (chunk_ptr)
> -		dummy_heaps[ION_HEAP_TYPE_CHUNK].base = virt_to_phys(chunk_ptr);
> -	else
> -		pr_err("ion_dummy: Could not allocate chunk\n");
> -
> -	for (i = 0; i < dummy_ion_pdata.nr; i++) {
> -		struct ion_platform_heap *heap_data = &dummy_ion_pdata.heaps[i];
> -
> -		if (heap_data->type == ION_HEAP_TYPE_CARVEOUT &&
> -		    !heap_data->base)
> -			continue;
> -
> -		if (heap_data->type == ION_HEAP_TYPE_CHUNK && !heap_data->base)
> -			continue;
> -
> -		heaps[i] = ion_heap_create(heap_data);
> -		if (IS_ERR_OR_NULL(heaps[i])) {
> -			err = PTR_ERR(heaps[i]);
> -			goto err;
> -		}
> -		ion_device_add_heap(idev, heaps[i]);
> -	}
> -	return 0;
> -err:
> -	for (i = 0; i < dummy_ion_pdata.nr; ++i)
> -		ion_heap_destroy(heaps[i]);
> -	kfree(heaps);
> -
> -	if (carveout_ptr) {
> -		free_pages_exact(carveout_ptr,
> -				 dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
> -		carveout_ptr = NULL;
> -	}
> -	if (chunk_ptr) {
> -		free_pages_exact(chunk_ptr,
> -				 dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
> -		chunk_ptr = NULL;
> -	}
> -	return err;
> -}
> -device_initcall(ion_dummy_init);
> -
> -static void __exit ion_dummy_exit(void)
> -{
> -	int i;
> -
> -	ion_device_destroy(idev);
> -
> -	for (i = 0; i < dummy_ion_pdata.nr; i++)
> -		ion_heap_destroy(heaps[i]);
> -	kfree(heaps);
> -
> -	if (carveout_ptr) {
> -		free_pages_exact(carveout_ptr,
> -				 dummy_heaps[ION_HEAP_TYPE_CARVEOUT].size);
> -		carveout_ptr = NULL;
> -	}
> -	if (chunk_ptr) {
> -		free_pages_exact(chunk_ptr,
> -				 dummy_heaps[ION_HEAP_TYPE_CHUNK].size);
> -		chunk_ptr = NULL;
> -	}
> -}
> -__exitcall(ion_dummy_exit);
> diff --git a/drivers/staging/android/ion/ion_of.c b/drivers/staging/android/ion/ion_of.c
> deleted file mode 100644
> index 7791c70..0000000
> --- a/drivers/staging/android/ion/ion_of.c
> +++ /dev/null
> @@ -1,184 +0,0 @@
> -/*
> - * Based on work from:
> - *   Andrew Andrianov <andrew@ncrmnt.org>
> - *   Google
> - *   The Linux Foundation
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#include <linux/init.h>
> -#include <linux/platform_device.h>
> -#include <linux/slab.h>
> -#include <linux/of.h>
> -#include <linux/of_platform.h>
> -#include <linux/of_address.h>
> -#include <linux/clk.h>
> -#include <linux/dma-mapping.h>
> -#include <linux/cma.h>
> -#include <linux/dma-contiguous.h>
> -#include <linux/io.h>
> -#include <linux/of_reserved_mem.h>
> -#include "ion.h"
> -#include "ion_priv.h"
> -#include "ion_of.h"
> -
> -static int ion_parse_dt_heap_common(struct device_node *heap_node,
> -				    struct ion_platform_heap *heap,
> -				    struct ion_of_heap *compatible)
> -{
> -	int i;
> -
> -	for (i = 0; compatible[i].name; i++) {
> -		if (of_device_is_compatible(heap_node, compatible[i].compat))
> -			break;
> -	}
> -
> -	if (!compatible[i].name)
> -		return -ENODEV;
> -
> -	heap->id = compatible[i].heap_id;
> -	heap->type = compatible[i].type;
> -	heap->name = compatible[i].name;
> -	heap->align = compatible[i].align;
> -
> -	/* Some kind of callback function pointer? */
> -
> -	pr_info("%s: id %d type %d name %s align %lx\n", __func__,
> -		heap->id, heap->type, heap->name, heap->align);
> -	return 0;
> -}
> -
> -static int ion_setup_heap_common(struct platform_device *parent,
> -				 struct device_node *heap_node,
> -				 struct ion_platform_heap *heap)
> -{
> -	int ret = 0;
> -
> -	switch (heap->type) {
> -	case ION_HEAP_TYPE_CARVEOUT:
> -	case ION_HEAP_TYPE_CHUNK:
> -		if (heap->base && heap->size)
> -			return 0;
> -
> -		ret = of_reserved_mem_device_init(heap->priv);
> -		break;
> -	default:
> -		break;
> -	}
> -
> -	return ret;
> -}
> -
> -struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
> -				       struct ion_of_heap *compatible)
> -{
> -	int num_heaps, ret;
> -	const struct device_node *dt_node = pdev->dev.of_node;
> -	struct device_node *node;
> -	struct ion_platform_heap *heaps;
> -	struct ion_platform_data *data;
> -	int i = 0;
> -
> -	num_heaps = of_get_available_child_count(dt_node);
> -
> -	if (!num_heaps)
> -		return ERR_PTR(-EINVAL);
> -
> -	heaps = devm_kzalloc(&pdev->dev,
> -			     sizeof(struct ion_platform_heap) * num_heaps,
> -			     GFP_KERNEL);
> -	if (!heaps)
> -		return ERR_PTR(-ENOMEM);
> -
> -	data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
> -			    GFP_KERNEL);
> -	if (!data)
> -		return ERR_PTR(-ENOMEM);
> -
> -	for_each_available_child_of_node(dt_node, node) {
> -		struct platform_device *heap_pdev;
> -
> -		ret = ion_parse_dt_heap_common(node, &heaps[i], compatible);
> -		if (ret)
> -			return ERR_PTR(ret);
> -
> -		heap_pdev = of_platform_device_create(node, heaps[i].name,
> -						      &pdev->dev);
> -		if (!heap_pdev)
> -			return ERR_PTR(-ENOMEM);
> -		heap_pdev->dev.platform_data = &heaps[i];
> -
> -		heaps[i].priv = &heap_pdev->dev;
> -
> -		ret = ion_setup_heap_common(pdev, node, &heaps[i]);
> -		if (ret)
> -			goto out_err;
> -		i++;
> -	}
> -
> -	data->heaps = heaps;
> -	data->nr = num_heaps;
> -	return data;
> -
> -out_err:
> -	for ( ; i >= 0; i--)
> -		if (heaps[i].priv)
> -			of_device_unregister(to_platform_device(heaps[i].priv));
> -
> -	return ERR_PTR(ret);
> -}
> -
> -void ion_destroy_platform_data(struct ion_platform_data *data)
> -{
> -	int i;
> -
> -	for (i = 0; i < data->nr; i++)
> -		if (data->heaps[i].priv)
> -			of_device_unregister(to_platform_device(
> -				data->heaps[i].priv));
> -}
> -
> -#ifdef CONFIG_OF_RESERVED_MEM
> -#include <linux/of.h>
> -#include <linux/of_fdt.h>
> -#include <linux/of_reserved_mem.h>
> -
> -static int rmem_ion_device_init(struct reserved_mem *rmem, struct device *dev)
> -{
> -	struct platform_device *pdev = to_platform_device(dev);
> -	struct ion_platform_heap *heap = pdev->dev.platform_data;
> -
> -	heap->base = rmem->base;
> -	heap->base = rmem->size;
> -	pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
> -		 heap->name, &rmem->base, &rmem->size, dev);
> -	return 0;
> -}
> -
> -static void rmem_ion_device_release(struct reserved_mem *rmem,
> -				    struct device *dev)
> -{
> -}
> -
> -static const struct reserved_mem_ops rmem_dma_ops = {
> -	.device_init	= rmem_ion_device_init,
> -	.device_release	= rmem_ion_device_release,
> -};
> -
> -static int __init rmem_ion_setup(struct reserved_mem *rmem)
> -{
> -	phys_addr_t size = rmem->size;
> -
> -	size = size / 1024;
> -
> -	pr_info("Ion memory setup at %pa size %pa MiB\n",
> -		&rmem->base, &size);
> -	rmem->ops = &rmem_dma_ops;
> -	return 0;
> -}
> -
> -RESERVEDMEM_OF_DECLARE(ion, "ion-region", rmem_ion_setup);
> -#endif
> diff --git a/drivers/staging/android/ion/ion_of.h b/drivers/staging/android/ion/ion_of.h
> deleted file mode 100644
> index 8241a17..0000000
> --- a/drivers/staging/android/ion/ion_of.h
> +++ /dev/null
> @@ -1,37 +0,0 @@
> -/*
> - * Based on work from:
> - *   Andrew Andrianov <andrew@ncrmnt.org>
> - *   Google
> - *   The Linux Foundation
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#ifndef _ION_OF_H
> -#define _ION_OF_H
> -
> -struct ion_of_heap {
> -	const char *compat;
> -	int heap_id;
> -	int type;
> -	const char *name;
> -	int align;
> -};
> -
> -#define PLATFORM_HEAP(_compat, _id, _type, _name) \
> -{ \
> -	.compat = _compat, \
> -	.heap_id = _id, \
> -	.type = _type, \
> -	.name = _name, \
> -	.align = PAGE_SIZE, \
> -}
> -
> -struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
> -					struct ion_of_heap *compatible);
> -
> -void ion_destroy_platform_data(struct ion_platform_data *data);
> -
> -#endif
> diff --git a/drivers/staging/android/ion/tegra/Makefile b/drivers/staging/android/ion/tegra/Makefile
> deleted file mode 100644
> index 808f1f5..0000000
> --- a/drivers/staging/android/ion/tegra/Makefile
> +++ /dev/null
> @@ -1 +0,0 @@
> -obj-$(CONFIG_ION_TEGRA) += tegra_ion.o
> diff --git a/drivers/staging/android/ion/tegra/tegra_ion.c b/drivers/staging/android/ion/tegra/tegra_ion.c
> deleted file mode 100644
> index 49e55e5..0000000
> --- a/drivers/staging/android/ion/tegra/tegra_ion.c
> +++ /dev/null
> @@ -1,80 +0,0 @@
> -/*
> - * drivers/gpu/tegra/tegra_ion.c
> - *
> - * Copyright (C) 2011 Google, Inc.
> - *
> - * This software is licensed under the terms of the GNU General Public
> - * License version 2, as published by the Free Software Foundation, and
> - * may be copied, distributed, and modified under those terms.
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - */
> -
> -#include <linux/err.h>
> -#include <linux/module.h>
> -#include <linux/platform_device.h>
> -#include <linux/slab.h>
> -#include "../ion.h"
> -#include "../ion_priv.h"
> -
> -static struct ion_device *idev;
> -static int num_heaps;
> -static struct ion_heap **heaps;
> -
> -static int tegra_ion_probe(struct platform_device *pdev)
> -{
> -	struct ion_platform_data *pdata = pdev->dev.platform_data;
> -	int err;
> -	int i;
> -
> -	num_heaps = pdata->nr;
> -
> -	heaps = devm_kcalloc(&pdev->dev, pdata->nr,
> -			     sizeof(struct ion_heap *), GFP_KERNEL);
> -
> -	idev = ion_device_create(NULL);
> -	if (IS_ERR(idev))
> -		return PTR_ERR(idev);
> -
> -	/* create the heaps as specified in the board file */
> -	for (i = 0; i < num_heaps; i++) {
> -		struct ion_platform_heap *heap_data = &pdata->heaps[i];
> -
> -		heaps[i] = ion_heap_create(heap_data);
> -		if (IS_ERR_OR_NULL(heaps[i])) {
> -			err = PTR_ERR(heaps[i]);
> -			goto err;
> -		}
> -		ion_device_add_heap(idev, heaps[i]);
> -	}
> -	platform_set_drvdata(pdev, idev);
> -	return 0;
> -err:
> -	for (i = 0; i < num_heaps; ++i)
> -		ion_heap_destroy(heaps[i]);
> -	return err;
> -}
> -
> -static int tegra_ion_remove(struct platform_device *pdev)
> -{
> -	struct ion_device *idev = platform_get_drvdata(pdev);
> -	int i;
> -
> -	ion_device_destroy(idev);
> -	for (i = 0; i < num_heaps; i++)
> -		ion_heap_destroy(heaps[i]);
> -	return 0;
> -}
> -
> -static struct platform_driver ion_driver = {
> -	.probe = tegra_ion_probe,
> -	.remove = tegra_ion_remove,
> -	.driver = { .name = "ion-tegra" }
> -};
> -
> -module_platform_driver(ion_driver);
> -
> -- 
> 2.7.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
> 
> Currently, all heaps are compiled in all the time. In switching to
> a better platform model, let's allow these to be compiled out for good
> measure.
> 
> Signed-off-by: Laura Abbott <labbott@redhat.com>

I'm not the biggest fan of making everything Kconfig-selectable. And the
#ifdef stuff doesn't look all that pretty. If we'd also use this
opportunity to split each heap into their own file I think this patch here
would be a lot more useful.

Anyway, no real opinion from me on this, just an idea.
-Daniel

> ---
>  drivers/staging/android/ion/Kconfig    | 32 ++++++++++++++++++++
>  drivers/staging/android/ion/Makefile   |  8 +++--
>  drivers/staging/android/ion/ion_priv.h | 53 ++++++++++++++++++++++++++++++++--
>  3 files changed, 87 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
> index 0c91b2b..2e97990 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -17,3 +17,35 @@ config ION_TEST
>  	  Choose this option to create a device that can be used to test the
>  	  kernel and device side ION functions.
>  
> +config ION_SYSTEM_HEAP
> +	bool "Ion system heap"
> +	depends on ION
> +	help
> +	  Choose this option to enable the Ion system heap. The system heap
> +	  is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config ION_CARVEOUT_HEAP
> +	bool "Ion carveout heap support"
> +	depends on ION
> +	help
> +	  Choose this option to enable carveout heaps with Ion. Carveout heaps
> +	  are backed by memory reserved from the system. Allocation times are
> +	  typically faster at the cost of memory not being used. Unless you
> +	  know your system has these regions, you should say N here.
> +
> +config ION_CHUNK_HEAP
> +	bool "Ion chunk heap support"
> +	depends on ION
> +	help
> +          Choose this option to enable chunk heaps with Ion. This heap is
> +	  similar in function the carveout heap but memory is broken down
> +	  into smaller chunk sizes, typically corresponding to a TLB size.
> +	  Unless you know your system has these regions, you should say N here.
> +
> +config ION_CMA_HEAP
> +	bool "Ion CMA heap support"
> +	depends on ION && CMA
> +	help
> +	  Choose this option to enable CMA heaps with Ion. This heap is backed
> +	  by the Contiguous Memory Allocator (CMA). If your system has these
> +	  regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index 9457090..eef022b 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,8 @@
> -obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o \
> -			ion_page_pool.o ion_system_heap.o \
> -			ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> +obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o
> +obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
> +obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
> +obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>  obj-$(CONFIG_ION_TEST) += ion_test.o
>  ifdef CONFIG_COMPAT
>  obj-$(CONFIG_ION) += compat_ion.o
> diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
> index b09bc7c..6eafe0d 100644
> --- a/drivers/staging/android/ion/ion_priv.h
> +++ b/drivers/staging/android/ion/ion_priv.h
> @@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
>   * heaps as appropriate.
>   */
>  
> +
>  struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
>  void ion_heap_destroy(struct ion_heap *heap);
> +
> +#ifdef CONFIG_ION_SYSTEM_HEAP
>  struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
>  void ion_system_heap_destroy(struct ion_heap *heap);
> -
>  struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *heap);
>  void ion_system_contig_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap * ion_system_heap_create(
> +	struct ion_platform_heap *unused)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
> +
> +static inline struct ion_heap *ion_system_contig_heap_create(
> +	struct ion_platform_heap *heap)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +
> +static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
> +#endif
> +
> +#ifdef CONFIG_ION_CARVEOUT_HEAP
>  struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
>  void ion_carveout_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap *ion_carveout_heap_create(
> +	struct ion_platform_heap *heap_data)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_carveout_heap_destroy(struct ion_heap *heap) { }
> +#endif
> +
> +#ifdef CONFIG_ION_CHUNK_HEAP
>  struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
>  void ion_chunk_heap_destroy(struct ion_heap *heap);
> +#else
> +static inline struct ion_heap *ion_chunk_heap_create(
> +	struct ion_platform_heap *heap_data)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_chunk_heap_destroy(struct ion_heap *heap) { }
> +
> +#endif
> +
> +#ifdef CONFIG_ION_CMA_HEAP
>  struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
>  void ion_cma_heap_destroy(struct ion_heap *heap);
> +#else
> +static inline struct ion_heap *ion_cma_heap_create(
> +	struct ion_platform_heap *data)
> +{
> +	return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_cma_heap_destroy(struct ion_heap *heap) { }
> +#endif
>  
>  /**
>   * functions for creating and destroying a heap pool -- allows you
> -- 
> 2.7.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 12/12] staging; android: ion: Enumerate all available heaps

[Daniel Vetter]

On Thu, Mar 02, 2017 at 01:44:44PM -0800, Laura Abbott wrote:
> 
> Practiaclly speaking, most Ion heaps are either going to be available
> all the time (system heaps) or found based off of the reserved-memory
> node. Parse the CMA and reserved-memory nodes to assign the heaps.
> 
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
>  drivers/staging/android/ion/Makefile        |  2 +-
>  drivers/staging/android/ion/ion_enumerate.c | 89 +++++++++++++++++++++++++++++
>  2 files changed, 90 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
> 
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index eef022b..4ebf655 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,4 +1,4 @@
> -obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o
> +obj-$(CONFIG_ION) +=	ion.o ion-ioctl.o ion_heap.o ion_enumerate.o
>  obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
>  obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
>  obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
> diff --git a/drivers/staging/android/ion/ion_enumerate.c b/drivers/staging/android/ion/ion_enumerate.c
> new file mode 100644
> index 0000000..21344c7
> --- /dev/null
> +++ b/drivers/staging/android/ion/ion_enumerate.c
> @@ -0,0 +1,89 @@
> +#include <linux/kernel.h>
> +#include <linux/cma.h>
> +
> +#include "ion.h"
> +#include "ion_priv.h"
> +
> +static struct ion_device *internal_dev;
> +static int heap_id = 2;
> +
> +static int ion_add_system_heap(void)
> +{
> +#ifdef CONFIG_ION_SYSTEM_HEAP
> +	struct ion_platform_heap pheap;
> +	struct ion_heap *heap;
> +
> +	pheap.type = ION_HEAP_TYPE_SYSTEM;
> +	pheap.id = heap_id++;
> +	pheap.name = "ion_system_heap";
> +
> +	heap = ion_heap_create(&pheap);
> +	if (!heap)
> +		return -ENODEV;
> +
> +	ion_device_add_heap(internal_dev, heap);
> +#endif
> +	return 0;
> +}
> +
> +static int ion_add_system_contig_heap(void)
> +{
> +#ifdef CONFIG_ION_SYSTEM_HEAP
> +	struct ion_platform_heap pheap;
> +	struct ion_heap *heap;
> +
> +	pheap.type = ION_HEAP_TYPE_SYSTEM_CONTIG;
> +	pheap.id = heap_id++;
> +	pheap.name = "ion_system_contig_heap";
> +
> +	heap = ion_heap_create(&pheap);
> +	if (!heap)
> +		return -ENODEV;
> +
> +	ion_device_add_heap(internal_dev, heap);
> +#endif
> +	return 0;
> +}
> +
> +#ifdef CONFIG_ION_CMA_HEAP
> +int __ion_add_cma_heaps(struct cma *cma, void *data)
> +{
> +	struct ion_heap *heap;
> +	struct ion_platform_heap pheap;
> +
> +	pheap.type = ION_HEAP_TYPE_DMA;
> +	pheap.id = heap_id++;
> +	pheap.name = cma_get_name(cma);
> +	pheap.priv = cma;
> +
> +	heap = ion_heap_create(&pheap);
> +	if (!heap)
> +		return -ENODEV;
> +
> +	ion_device_add_heap(internal_dev, heap);
> +	return 0;
> +}
> +#endif
> +
> +
> +static int ion_add_cma_heaps(void)
> +{
> +#ifdef CONFIG_ION_CMA_HEAP
> +	cma_for_each_area(__ion_add_cma_heaps, NULL);
> +#endif
> +	return 0;
> +}
> +
> +int ion_enumerate(void)
> +{
> +	internal_dev = ion_device_create(NULL);
> +	if (IS_ERR(internal_dev))
> +		return PTR_ERR(internal_dev);
> +
> +	ion_add_system_heap();
> +	ion_add_system_contig_heap();
> +
> +	ion_add_cma_heaps();
> +	return 0;
> +}
> +subsys_initcall(ion_enumerate);

If we'd split each heap into its own file I think we could just put
initcalls into each of them, avoiding the need for so much #ifdef all
over.

That should also help when we add more specific heaps like the SMA one.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Dan Carpenter]

On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
>  					enum dma_data_direction direction)
>  {
>  	struct dma_buf *dmabuf = attachment->dmabuf;
>  	struct ion_buffer *buffer = dmabuf->priv;
> +	struct sg_table *table;
> +	int ret;
> +
> +	/*
> +	 * TODO: Need to sync wrt CPU or device completely owning?
> +	 */
> +
> +	table = dup_sg_table(buffer->sg_table);
>  
> -	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> -	return dup_sg_table(buffer->sg_table);
> +	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> +			direction)){
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +
> +err:
> +	free_duped_table(table);
> +	return ERR_PTR(ret);

ret isn't initialized on success.

>  }
>  

regards,
dan carpenter

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Eric Engestrom]

On Friday, 2017-03-03 14:04:26 +0300, Dan Carpenter wrote:
> On Thu, Mar 02, 2017 at 01:44:36PM -0800, Laura Abbott wrote:
> >  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
> >  					enum dma_data_direction direction)
> >  {
> >  	struct dma_buf *dmabuf = attachment->dmabuf;
> >  	struct ion_buffer *buffer = dmabuf->priv;
> > +	struct sg_table *table;
> > +	int ret;
> > +
> > +	/*
> > +	 * TODO: Need to sync wrt CPU or device completely owning?
> > +	 */
> > +
> > +	table = dup_sg_table(buffer->sg_table);
> >  
> > -	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> > -	return dup_sg_table(buffer->sg_table);
> > +	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> > +			direction)){
> > +		ret = -ENOMEM;
> > +		goto err;
> > +	}

Actually, I think `ret` should be left uninitialised on success,
what's really missing is this return before the `err:` label:

+	return table;


> > +
> > +err:
> > +	free_duped_table(table);
> > +	return ERR_PTR(ret);
> 
> ret isn't initialized on success.
> 
> >  }
> >  
> 
> regards,
> dan carpenter

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-03 11:27 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
> On Fri, Mar 03, 2017 at 11:04:33AM +0100, Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
>> > Hi,
>> >
>> > There's been some recent discussions[1] about Ion-like frameworks. There's
>> > apparently interest in just keeping Ion since it works reasonablly well.
>> > This series does what should be the final clean ups for it to possibly be
>> > moved out of staging.
>> >
>> > This includes the following:
>> > - Some general clean up and removal of features that never got a lot of use
>> >   as far as I can tell.
>> > - Fixing up the caching. This is the series I proposed back in December[2]
>> >   but never heard any feedback on. It will certainly break existing
>> >   applications that rely on the implicit caching. I'd rather make an effort
>> >   to move to a model that isn't going directly against the establishement
>> >   though.
>> > - Fixing up the platform support. The devicetree approach was never well
>> >   recieved by DT maintainers. The proposal here is to think of Ion less as
>> >   specifying requirements and more of a framework for exposing memory to
>> >   userspace.
>> > - CMA allocations now happen without the need of a dummy device structure.
>> >   This fixes a bunch of the reasons why I attempted to add devicetree
>> >   support before.
>> >
>> > I've had problems getting feedback in the past so if I don't hear any major
>> > objections I'm going to send out with the RFC dropped to be picked up.
>> > The only reason there isn't a patch to come out of staging is to discuss any
>> > other changes to the ABI people might want. Once this comes out of staging,
>> > I really don't want to mess with the ABI.
>> >
>> > Feedback appreciated.
>>
>> Imo looks all good. And I just realized that cross-checking with the TODO,
>> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.
>
> One more for the todo: Add rst/sphinx documentation for ION. That's also
> always a good excuse to review the internal interfaces and exported
> symbols. But we can do that after destaging ...
> -Daniel

Removing alignment looks good for me but why not also remove it from
struct ion_allocation_data since the field become useless ?

Also does someone use ion_user_handle_t handle ? Can we directly export
a dma-buf file descriptor ?

Benjamin

>
>>
>> Otherwise I looked through the patches, looks all really reasonable.
>>
>> Wrt merging, my experience from destaging the android syncpt stuff was
>> that merging the patches through the staging tree lead to lots of
>> cross-tree issues with the gpu folks wanting to use that. Ion will
>> probably run into similar things, so I'd propose we pull these cleanup
>> patches and the eventual de-staging in throught drm. Yes that defacto
>> means I'm also volunteering myself a bit :-)
>>
>> In the end we could put it all into drivers/gpu/ion or something like
>> that.
>>
>> Thoughts? Greg?
>> -Daniel
>>
>>
>> >
>> > Thanks,
>> > Laura
>> >
>> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
>> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
>> >
>> > Laura Abbott (12):
>> >   staging: android: ion: Remove dmap_cnt
>> >   staging: android: ion: Remove alignment from allocation field
>> >   staging: android: ion: Duplicate sg_table
>> >   staging: android: ion: Call dma_map_sg for syncing and mapping
>> >   staging: android: ion: Remove page faulting support
>> >   staging: android: ion: Remove crufty cache support
>> >   staging: android: ion: Remove old platform support
>> >   cma: Store a name in the cma structure
>> >   cma: Introduce cma_for_each_area
>> >   staging: android: ion: Use CMA APIs directly
>> >   staging: android: ion: Make Ion heaps selectable
>> >   staging; android: ion: Enumerate all available heaps
>> >
>> >  drivers/base/dma-contiguous.c                      |   5 +-
>> >  drivers/staging/android/ion/Kconfig                |  51 ++--
>> >  drivers/staging/android/ion/Makefile               |  14 +-
>> >  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
>> >  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
>> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
>> >  drivers/staging/android/ion/ion-ioctl.c            |   6 -
>> >  drivers/staging/android/ion/ion.c                  | 282 ++++++---------------
>> >  drivers/staging/android/ion/ion.h                  |   5 +-
>> >  drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
>> >  drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
>> >  drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
>> >  drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
>> >  drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
>> >  drivers/staging/android/ion/ion_of.c               | 184 --------------
>> >  drivers/staging/android/ion/ion_of.h               |  37 ---
>> >  drivers/staging/android/ion/ion_page_pool.c        |   3 -
>> >  drivers/staging/android/ion/ion_priv.h             |  57 ++++-
>> >  drivers/staging/android/ion/ion_system_heap.c      |  14 +-
>> >  drivers/staging/android/ion/tegra/Makefile         |   1 -
>> >  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
>> >  include/linux/cma.h                                |   6 +-
>> >  mm/cma.c                                           |  25 +-
>> >  mm/cma.h                                           |   1 +
>> >  mm/cma_debug.c                                     |   2 +-
>> >  25 files changed, 312 insertions(+), 958 deletions(-)
>> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>> >  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>> >  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>> >  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
>> >  delete mode 100644 drivers/staging/android/ion/ion_of.c
>> >  delete mode 100644 drivers/staging/android/ion/ion_of.h
>> >  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>> >  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
>> >
>> > --
>> > 2.7.4
>> >
>> > --
>> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> > the body to majordomo@kvack.org.  For more info on Linux MM,
>> > see: http://www.linux-mm.org/ .
>> > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Michal Hocko]

On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.
> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.

Could you recapitulate concerns preventing the code being merged
normally rather than through the staging tree and how they were
addressed?
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Laura,

Thank you for the patches.

On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote:
> Hi,
> 
> There's been some recent discussions[1] about Ion-like frameworks. There's
> apparently interest in just keeping Ion since it works reasonablly well.
> This series does what should be the final clean ups for it to possibly be
> moved out of staging.
> 
> This includes the following:
> - Some general clean up and removal of features that never got a lot of use
>   as far as I can tell.
> - Fixing up the caching. This is the series I proposed back in December[2]
>   but never heard any feedback on. It will certainly break existing
>   applications that rely on the implicit caching. I'd rather make an effort
>   to move to a model that isn't going directly against the establishement
>   though.
> - Fixing up the platform support. The devicetree approach was never well
>   recieved by DT maintainers. The proposal here is to think of Ion less as
>   specifying requirements and more of a framework for exposing memory to
>   userspace.

That's where most of my concerns with ion are. I still strongly believe that 
the heap-based approach is inherently flawed, as it would need to be 
configured for each device according to product-specific use cases. That's not 
something that could be easily shipped with a generic distribution. We should 
replace that with a constraint-based system.

> - CMA allocations now happen without the need of a dummy device structure.
>   This fixes a bunch of the reasons why I attempted to add devicetree
>   support before.
> 
> I've had problems getting feedback in the past so if I don't hear any major
> objections I'm going to send out with the RFC dropped to be picked up.
> The only reason there isn't a patch to come out of staging is to discuss any
> other changes to the ABI people might want. Once this comes out of staging,
> I really don't want to mess with the ABI.
> 
> Feedback appreciated.
> 
> Thanks,
> Laura
> 
> [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> 
> Laura Abbott (12):
>   staging: android: ion: Remove dmap_cnt
>   staging: android: ion: Remove alignment from allocation field
>   staging: android: ion: Duplicate sg_table
>   staging: android: ion: Call dma_map_sg for syncing and mapping
>   staging: android: ion: Remove page faulting support
>   staging: android: ion: Remove crufty cache support
>   staging: android: ion: Remove old platform support
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Make Ion heaps selectable
>   staging; android: ion: Enumerate all available heaps
> 
>  drivers/base/dma-contiguous.c                      |   5 +-
>  drivers/staging/android/ion/Kconfig                |  51 ++--
>  drivers/staging/android/ion/Makefile               |  14 +-
>  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
>  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
>  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
>  drivers/staging/android/ion/ion-ioctl.c            |   6 -
>  drivers/staging/android/ion/ion.c                  | 282 +++++-------------
>  drivers/staging/android/ion/ion.h                  |   5 +-
>  drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
>  drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
>  drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
>  drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
>  drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
>  drivers/staging/android/ion/ion_of.c               | 184 --------------
>  drivers/staging/android/ion/ion_of.h               |  37 ---
>  drivers/staging/android/ion/ion_page_pool.c        |   3 -
>  drivers/staging/android/ion/ion_priv.h             |  57 ++++-
>  drivers/staging/android/ion/ion_system_heap.c      |  14 +-
>  drivers/staging/android/ion/tegra/Makefile         |   1 -
>  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
>  include/linux/cma.h                                |   6 +-
>  mm/cma.c                                           |  25 +-
>  mm/cma.h                                           |   1 +
>  mm/cma_debug.c                                     |   2 +-
>  25 files changed, 312 insertions(+), 958 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
>  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
>  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
>  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
>  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.c
>  delete mode 100644 drivers/staging/android/ion/ion_of.h
>  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
>  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laurent Pinchart]

Hi Laura,

Thank you for the patch.

On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
> Technically, calling dma_buf_map_attachment should return a buffer
> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
> ensure this happens. As a side effect, this lets Ion buffers take
> advantage of the dma_buf sync ioctls.
> 
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
>  drivers/staging/android/ion/ion.c | 101 +++++++++++++++++------------------
>  1 file changed, 50 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c index ce4adac..a931b30 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
>  }
>  EXPORT_SYMBOL(ion_client_destroy);
> 
> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
> -				       struct device *dev,
> -				       enum dma_data_direction direction);
> -
>  static struct sg_table *dup_sg_table(struct sg_table *table)
>  {
>  	struct sg_table *new_table;
> @@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table
> *table) return new_table;
>  }
> 
> +static void free_duped_table(struct sg_table *table)
> +{
> +	sg_free_table(table);
> +	kfree(table);
> +}
> +
>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
> *attachment, enum dma_data_direction direction)
>  {
>  	struct dma_buf *dmabuf = attachment->dmabuf;
>  	struct ion_buffer *buffer = dmabuf->priv;
> +	struct sg_table *table;
> +	int ret;
> +
> +	/*
> +	 * TODO: Need to sync wrt CPU or device completely owning?
> +	 */
> +
> +	table = dup_sg_table(buffer->sg_table);
> 
> -	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
> -	return dup_sg_table(buffer->sg_table);
> +	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> +			direction)){
> +		ret = -ENOMEM;
> +		goto err;
> +	}
> +
> +err:
> +	free_duped_table(table);
> +	return ERR_PTR(ret);
>  }
> 
>  static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>  			      struct sg_table *table,
>  			      enum dma_data_direction direction)
>  {
> -	sg_free_table(table);
> -	kfree(table);
> +	dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> +	free_duped_table(table);
>  }
> 
>  void ion_pages_sync_for_device(struct device *dev, struct page *page,
> @@ -864,38 +881,6 @@ struct ion_vma_list {
>  	struct vm_area_struct *vma;
>  };
> 
> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
> -				       struct device *dev,
> -				       enum dma_data_direction dir)
> -{
> -	struct ion_vma_list *vma_list;
> -	int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
> -	int i;
> -
> -	pr_debug("%s: syncing for device %s\n", __func__,
> -		 dev ? dev_name(dev) : "null");
> -
> -	if (!ion_buffer_fault_user_mappings(buffer))
> -		return;
> -
> -	mutex_lock(&buffer->lock);
> -	for (i = 0; i < pages; i++) {
> -		struct page *page = buffer->pages[i];
> -
> -		if (ion_buffer_page_is_dirty(page))
> -			ion_pages_sync_for_device(dev, ion_buffer_page(page),
> -						  PAGE_SIZE, dir);
> -
> -		ion_buffer_page_clean(buffer->pages + i);
> -	}
> -	list_for_each_entry(vma_list, &buffer->vmas, list) {
> -		struct vm_area_struct *vma = vma_list->vma;
> -
> -		zap_page_range(vma, vma->vm_start, vma->vm_end - vma-
>vm_start);
> -	}
> -	mutex_unlock(&buffer->lock);
> -}
> -
>  static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
>  	struct ion_buffer *buffer = vma->vm_private_data;
> @@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct
> dma_buf *dmabuf, struct ion_buffer *buffer = dmabuf->priv;
>  	void *vaddr;
> 
> -	if (!buffer->heap->ops->map_kernel) {
> -		pr_err("%s: map kernel is not implemented by this heap.\n",
> -		       __func__);
> -		return -ENODEV;
> +	/*
> +	 * TODO: Move this elsewhere because we don't always need a vaddr
> +	 */
> +	if (buffer->heap->ops->map_kernel) {
> +		mutex_lock(&buffer->lock);
> +		vaddr = ion_buffer_kmap_get(buffer);
> +		mutex_unlock(&buffer->lock);
>  	}
> 
> -	mutex_lock(&buffer->lock);
> -	vaddr = ion_buffer_kmap_get(buffer);
> -	mutex_unlock(&buffer->lock);
> -	return PTR_ERR_OR_ZERO(vaddr);
> +	/*
> +	 * Close enough right now? Flag to skip sync?
> +	 */
> +	if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
> +			buffer->sg_table->nents,
> +                        DMA_BIDIRECTIONAL))

Aren't the dma_(un)map_* calls supposed to take a real, physical device as 
their first argument ? Beside, this doesn't seem to be the right place to 
create the mapping, as you mentioned in the commit message the buffer should 
be mapped in the dma_buf map handler. This is something that needs to be 
fixed, especially in the light of the comment in ion_buffer_create():

        /*
         * this will set up dma addresses for the sglist -- it is not
         * technically correct as per the dma api -- a specific
         * device isn't really taking ownership here.  However, in practice on
         * our systems the only dma_address space is physical addresses.
         * Additionally, we can't afford the overhead of invalidating every
         * allocation via dma_map_sg. The implicit contract here is that
         * memory coming from the heaps is ready for dma, ie if it has a
         * cached mapping that mapping has been invalidated
         */

That's a showstopper in my opinion, the DMA address space can't be restricted 
to physical addresses, IOMMU have to be supported.

> +		return -ENOMEM;
> +
> +	return 0;
>  }
> 
>  static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> @@ -1031,9 +1024,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf
> *dmabuf, {
>  	struct ion_buffer *buffer = dmabuf->priv;
> 
> -	mutex_lock(&buffer->lock);
> -	ion_buffer_kmap_put(buffer);
> -	mutex_unlock(&buffer->lock);
> +	if (buffer->heap->ops->map_kernel) {
> +		mutex_lock(&buffer->lock);
> +		ion_buffer_kmap_put(buffer);
> +		mutex_unlock(&buffer->lock);
> +	}
> +
> +	dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
> +			buffer->sg_table->nents,
> +			DMA_BIDIRECTIONAL);
> 
>  	return 0;
>  }

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laurent Pinchart]

Hi Daniel,

On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> > Now that we call dma_map in the dma_buf API callbacks there is no need
> > to use the existing cache APIs. Remove the sync ioctl and the existing
> > bad dma_sync calls. Explicit caching can be handled with the dma_buf
> > sync API.
> > 
> > Signed-off-by: Laura Abbott <labbott@redhat.com>
> > ---
> > 
> >  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
> >  drivers/staging/android/ion/ion.c               | 40 --------------------
> >  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
> >  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
> >  drivers/staging/android/ion/ion_page_pool.c     |  3 --
> >  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
> >  6 files changed, 65 deletions(-)
> > 
> > diff --git a/drivers/staging/android/ion/ion-ioctl.c
> > b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
> > --- a/drivers/staging/android/ion/ion-ioctl.c
> > +++ b/drivers/staging/android/ion/ion-ioctl.c
> > @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> > unsigned long arg)> 
> >  			data.handle.handle = handle->id;
> >  		
> >  		break;
> >  	
> >  	}
> > 
> > -	case ION_IOC_SYNC:
> > -	{
> > -		ret = ion_sync_for_device(client, data.fd.fd);
> > -		break;
> > -	}
> 
> You missed the case ION_IOC_SYNC: in compat_ion.c.
> 
> While at it: Should we also remove the entire custom_ioctl infrastructure?
> It's entirely unused afaict, and for a pure buffer allocator I don't see
> any need to have custom ioctl.

I second that, if you want to make ion a standard API, then we certainly don't 
want any custom ioctl.

> More code to remove potentially:
> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>   would allow us to remove compat_ion.c entirely.
> 
> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>   still need to be able to import anything. All the cache flushing/mapping
>   is done through dma-buf ops/ioctls.
> 
> 
> With the case in compat_ion.c also removed, this patch is:
> 
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> >  	case ION_IOC_CUSTOM:
> >  	{
> >  	
> >  		if (!dev->custom_ioctl)
> > 
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index 8eef1d7..c3c316f 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,> 
> >  	free_duped_table(table);
> >  
> >  }
> > 
> > -void ion_pages_sync_for_device(struct device *dev, struct page *page,
> > -			       size_t size, enum dma_data_direction dir)
> > -{
> > -	struct scatterlist sg;
> > -
> > -	sg_init_table(&sg, 1);
> > -	sg_set_page(&sg, page, size, 0);
> > -	/*
> > -	 * This is not correct - sg_dma_address needs a dma_addr_t that is 
valid
> > -	 * for the targeted device, but this works on the currently targeted
> > -	 * hardware.
> > -	 */
> > -	sg_dma_address(&sg) = page_to_phys(page);
> > -	dma_sync_sg_for_device(dev, &sg, 1, dir);
> > -}
> > -
> > 
> >  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> >  {
> >  
> >  	struct ion_buffer *buffer = dmabuf->priv;
> > 
> > @@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct
> > ion_client *client, int fd)> 
> >  }
> >  EXPORT_SYMBOL(ion_import_dma_buf_fd);
> > 
> > -int ion_sync_for_device(struct ion_client *client, int fd)
> > -{
> > -	struct dma_buf *dmabuf;
> > -	struct ion_buffer *buffer;
> > -
> > -	dmabuf = dma_buf_get(fd);
> > -	if (IS_ERR(dmabuf))
> > -		return PTR_ERR(dmabuf);
> > -
> > -	/* if this memory came from ion */
> > -	if (dmabuf->ops != &dma_buf_ops) {
> > -		pr_err("%s: can not sync dmabuf from another exporter\n",
> > -		       __func__);
> > -		dma_buf_put(dmabuf);
> > -		return -EINVAL;
> > -	}
> > -	buffer = dmabuf->priv;
> > -
> > -	dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
> > -			       buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> > -	dma_buf_put(dmabuf);
> > -	return 0;
> > -}
> > -
> > 
> >  int ion_query_heaps(struct ion_client *client, struct ion_heap_query
> >  *query) {
> >  
> >  	struct ion_device *dev = client->dev;
> > 
> > diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
> > b/drivers/staging/android/ion/ion_carveout_heap.c index 9bf8e98..e0e360f
> > 100644
> > --- a/drivers/staging/android/ion/ion_carveout_heap.c
> > +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> > @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer
> > *buffer)> 
> >  	ion_heap_buffer_zero(buffer);
> > 
> > -	if (ion_buffer_cached(buffer))
> > -		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> > -				       DMA_BIDIRECTIONAL);
> > -
> > 
> >  	ion_carveout_free(heap, paddr, buffer->size);
> >  	sg_free_table(table);
> >  	kfree(table);
> > 
> > @@ -128,8 +124,6 @@ struct ion_heap *ion_carveout_heap_create(struct
> > ion_platform_heap *heap_data)> 
> >  	page = pfn_to_page(PFN_DOWN(heap_data->base));
> >  	size = heap_data->size;
> > 
> > -	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> > -
> > 
> >  	ret = ion_heap_pages_zero(page, size, 
pgprot_writecombine(PAGE_KERNEL));
> >  	if (ret)
> >  	
> >  		return ERR_PTR(ret);
> > 
> > diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
> > b/drivers/staging/android/ion/ion_chunk_heap.c index 8c41889..46e13f6
> > 100644
> > --- a/drivers/staging/android/ion/ion_chunk_heap.c
> > +++ b/drivers/staging/android/ion/ion_chunk_heap.c
> > @@ -101,10 +101,6 @@ static void ion_chunk_heap_free(struct ion_buffer
> > *buffer)> 
> >  	ion_heap_buffer_zero(buffer);
> > 
> > -	if (ion_buffer_cached(buffer))
> > -		dma_sync_sg_for_device(NULL, table->sgl, table->nents,
> > -				       DMA_BIDIRECTIONAL);
> > -
> > 
> >  	for_each_sg(table->sgl, sg, table->nents, i) {
> >  	
> >  		gen_pool_free(chunk_heap->pool, page_to_phys(sg_page(sg)),
> >  		
> >  			      sg->length);
> > 
> > @@ -132,8 +128,6 @@ struct ion_heap *ion_chunk_heap_create(struct
> > ion_platform_heap *heap_data)> 
> >  	page = pfn_to_page(PFN_DOWN(heap_data->base));
> >  	size = heap_data->size;
> > 
> > -	ion_pages_sync_for_device(NULL, page, size, DMA_BIDIRECTIONAL);
> > -
> > 
> >  	ret = ion_heap_pages_zero(page, size, 
pgprot_writecombine(PAGE_KERNEL));
> >  	if (ret)
> >  	
> >  		return ERR_PTR(ret);
> > 
> > diff --git a/drivers/staging/android/ion/ion_page_pool.c
> > b/drivers/staging/android/ion/ion_page_pool.c index aea89c1..532eda7
> > 100644
> > --- a/drivers/staging/android/ion/ion_page_pool.c
> > +++ b/drivers/staging/android/ion/ion_page_pool.c
> > @@ -30,9 +30,6 @@ static void *ion_page_pool_alloc_pages(struct
> > ion_page_pool *pool)> 
> >  	if (!page)
> >  	
> >  		return NULL;
> > 
> > -	if (!pool->cached)
> > -		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << pool-
>order,
> > -					  DMA_BIDIRECTIONAL);
> > 
> >  	return page;
> >  
> >  }
> > 
> > diff --git a/drivers/staging/android/ion/ion_system_heap.c
> > b/drivers/staging/android/ion/ion_system_heap.c index 6cb2fe7..a33331b
> > 100644
> > --- a/drivers/staging/android/ion/ion_system_heap.c
> > +++ b/drivers/staging/android/ion/ion_system_heap.c
> > @@ -75,9 +75,6 @@ static struct page *alloc_buffer_page(struct
> > ion_system_heap *heap,> 
> >  	page = ion_page_pool_alloc(pool);
> > 
> > -	if (cached)
> > -		ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order,
> > -					  DMA_BIDIRECTIONAL);
> > 
> >  	return page;
> >  
> >  }
> > 
> > @@ -401,8 +398,6 @@ static int ion_system_contig_heap_allocate(struct
> > ion_heap *heap,> 
> >  	buffer->sg_table = table;
> > 
> > -	ion_pages_sync_for_device(NULL, page, len, DMA_BIDIRECTIONAL);
> > -
> > 
> >  	return 0;
> >  
> >  free_table:

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

Hi Laura,

Thank you for the patch.

On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also avoids awkward
> caching questions.

If the DMA mapping API isn't suitable for today's requirements anymore, I 
believe that's what needs to be fixed, instead of working around the problem 
by introducing another use-case-specific API.

> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
>  drivers/staging/android/ion/ion_cma_heap.c | 97 +++++++--------------------
>  1 file changed, 26 insertions(+), 71 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..6838825 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
>  #include <linux/slab.h>
>  #include <linux/errno.h>
>  #include <linux/err.h>
> -#include <linux/dma-mapping.h>
> +#include <linux/cma.h>
> +#include <linux/scatterlist.h>
> 
>  #include "ion.h"
>  #include "ion_priv.h"
> 
>  struct ion_cma_heap {
>  	struct ion_heap heap;
> -	struct device *dev;
> +	struct cma *cma;
>  };
> 
>  #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
> 
> -struct ion_cma_buffer_info {
> -	void *cpu_addr;
> -	dma_addr_t handle;
> -	struct sg_table *table;
> -};
> -
> 
>  /* ION CMA heap operations functions */
>  static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer
> *buffer, @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap
> *heap, struct ion_buffer *buffer, unsigned long flags)
>  {
>  	struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> -	struct device *dev = cma_heap->dev;
> -	struct ion_cma_buffer_info *info;
> -
> -	dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> -	if (buffer->flags & ION_FLAG_CACHED)
> -		return -EINVAL;
> +	struct sg_table *table;
> +	struct page *pages;
> +	int ret;
> 
> -	info = kzalloc(sizeof(*info), GFP_KERNEL);
> -	if (!info)
> +	pages = cma_alloc(cma_heap->cma, len, 0);
> +	if (!pages)
>  		return -ENOMEM;
> 
> -	info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> -						GFP_HIGHUSER | __GFP_ZERO);
> -
> -	if (!info->cpu_addr) {
> -		dev_err(dev, "Fail to allocate buffer\n");
> +	table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> +	if (!table)
>  		goto err;
> -	}
> 
> -	info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> -	if (!info->table)
> +	ret = sg_alloc_table(table, 1, GFP_KERNEL);
> +	if (ret)
>  		goto free_mem;
> 
> -	if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> -			    len))
> -		goto free_table;
> -	/* keep this for memory release */
> -	buffer->priv_virt = info;
> -	buffer->sg_table = info->table;
> -	dev_dbg(dev, "Allocate buffer %p\n", buffer);
> +	sg_set_page(table->sgl, pages, len, 0);
> +
> +	buffer->priv_virt = pages;
> +	buffer->sg_table = table;
>  	return 0;
> 
> -free_table:
> -	kfree(info->table);
>  free_mem:
> -	dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> +	kfree(table);
>  err:
> -	kfree(info);
> +	cma_release(cma_heap->cma, pages, buffer->size);
>  	return -ENOMEM;
>  }
> 
>  static void ion_cma_free(struct ion_buffer *buffer)
>  {
>  	struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> -	struct device *dev = cma_heap->dev;
> -	struct ion_cma_buffer_info *info = buffer->priv_virt;
> +	struct page *pages = buffer->priv_virt;
> 
> -	dev_dbg(dev, "Release buffer %p\n", buffer);
>  	/* release memory */
> -	dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
> +	cma_release(cma_heap->cma, pages, buffer->size);
>  	/* release sg table */
> -	sg_free_table(info->table);
> -	kfree(info->table);
> -	kfree(info);
> -}
> -
> -static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
> -			struct vm_area_struct *vma)
> -{
> -	struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> -	struct device *dev = cma_heap->dev;
> -	struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> -	return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> -				 buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> -				struct ion_buffer *buffer)
> -{
> -	struct ion_cma_buffer_info *info = buffer->priv_virt;
> -	/* kernel memory mapping has been done at allocation time */
> -	return info->cpu_addr;
> -}
> -
> -static void ion_cma_unmap_kernel(struct ion_heap *heap,
> -				 struct ion_buffer *buffer)
> -{
> +	sg_free_table(buffer->sg_table);
> +	kfree(buffer->sg_table);
>  }
> 
>  static struct ion_heap_ops ion_cma_ops = {
>  	.allocate = ion_cma_allocate,
>  	.free = ion_cma_free,
> -	.map_user = ion_cma_mmap,
> -	.map_kernel = ion_cma_map_kernel,
> -	.unmap_kernel = ion_cma_unmap_kernel,
> +	.map_user = ion_heap_map_user,
> +	.map_kernel = ion_heap_map_kernel,
> +	.unmap_kernel = ion_heap_unmap_kernel,
>  };
> 
>  struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> @@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct
> ion_platform_heap *data) * get device from private heaps data, later it
> will be
>  	 * used to make the link with reserved CMA memory
>  	 */
> -	cma_heap->dev = data->priv;
> +	cma_heap->cma = data->priv;
>  	cma_heap->heap.type = ION_HEAP_TYPE_DMA;
>  	return &cma_heap->heap;
>  }

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Daniel,

On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
> > Hi,
> > 
> > There's been some recent discussions[1] about Ion-like frameworks. There's
> > apparently interest in just keeping Ion since it works reasonablly well.
> > This series does what should be the final clean ups for it to possibly be
> > moved out of staging.
> > 
> > This includes the following:
> > - Some general clean up and removal of features that never got a lot of
> >   use as far as I can tell.
> > 
> > - Fixing up the caching. This is the series I proposed back in December[2]
> >   but never heard any feedback on. It will certainly break existing
> >   applications that rely on the implicit caching. I'd rather make an
> >   effort to move to a model that isn't going directly against the
> >   establishement though.
> > 
> > - Fixing up the platform support. The devicetree approach was never well
> >   recieved by DT maintainers. The proposal here is to think of Ion less as
> >   specifying requirements and more of a framework for exposing memory to
> >   userspace.
> > 
> > - CMA allocations now happen without the need of a dummy device structure.
> >   This fixes a bunch of the reasons why I attempted to add devicetree
> >   support before.
> > 
> > I've had problems getting feedback in the past so if I don't hear any
> > major objections I'm going to send out with the RFC dropped to be picked
> > up. The only reason there isn't a patch to come out of staging is to
> > discuss any other changes to the ABI people might want. Once this comes
> > out of staging, I really don't want to mess with the ABI.
> > 
> > Feedback appreciated.
> 
> Imo looks all good. And I just realized that cross-checking with the TODO,
> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.
> 
> Otherwise I looked through the patches, looks all really reasonable.

Two more items that need to be addressed in my opinion :

- Let's not export the ion_client API, we don't want drivers to be ion-
specific. Only the dma-buf interface should be visible to drivers.

- I haven't seen any proposal how a heap-based solution could be used in a 
generic distribution. This needs to be figured out before committing to any 
API/ABI.

> Wrt merging, my experience from destaging the android syncpt stuff was
> that merging the patches through the staging tree lead to lots of
> cross-tree issues with the gpu folks wanting to use that. Ion will
> probably run into similar things, so I'd propose we pull these cleanup
> patches and the eventual de-staging in throught drm. Yes that defacto
> means I'm also volunteering myself a bit :-)
> 
> In the end we could put it all into drivers/gpu/ion or something like
> that.
> 
> Thoughts? Greg?
> -Daniel
> 
> > Thanks,
> > Laura
> > 
> > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2
> > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2
> > 
> > Laura Abbott (12):
> >   staging: android: ion: Remove dmap_cnt
> >   staging: android: ion: Remove alignment from allocation field
> >   staging: android: ion: Duplicate sg_table
> >   staging: android: ion: Call dma_map_sg for syncing and mapping
> >   staging: android: ion: Remove page faulting support
> >   staging: android: ion: Remove crufty cache support
> >   staging: android: ion: Remove old platform support
> >   cma: Store a name in the cma structure
> >   cma: Introduce cma_for_each_area
> >   staging: android: ion: Use CMA APIs directly
> >   staging: android: ion: Make Ion heaps selectable
> >   staging; android: ion: Enumerate all available heaps
> >  
> >  drivers/base/dma-contiguous.c                      |   5 +-
> >  drivers/staging/android/ion/Kconfig                |  51 ++--
> >  drivers/staging/android/ion/Makefile               |  14 +-
> >  drivers/staging/android/ion/hisilicon/Kconfig      |   5 -
> >  drivers/staging/android/ion/hisilicon/Makefile     |   1 -
> >  drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 ---------
> >  drivers/staging/android/ion/ion-ioctl.c            |   6 -
> >  drivers/staging/android/ion/ion.c                  | 282
> >  ++++++--------------- drivers/staging/android/ion/ion.h                 
> >  |   5 +-
> >  drivers/staging/android/ion/ion_carveout_heap.c    |  16 +-
> >  drivers/staging/android/ion/ion_chunk_heap.c       |  15 +-
> >  drivers/staging/android/ion/ion_cma_heap.c         | 102 ++------
> >  drivers/staging/android/ion/ion_dummy_driver.c     | 156 ------------
> >  drivers/staging/android/ion/ion_enumerate.c        |  89 +++++++
> >  drivers/staging/android/ion/ion_of.c               | 184 --------------
> >  drivers/staging/android/ion/ion_of.h               |  37 ---
> >  drivers/staging/android/ion/ion_page_pool.c        |   3 -
> >  drivers/staging/android/ion/ion_priv.h             |  57 ++++-
> >  drivers/staging/android/ion/ion_system_heap.c      |  14 +-
> >  drivers/staging/android/ion/tegra/Makefile         |   1 -
> >  drivers/staging/android/ion/tegra/tegra_ion.c      |  80 ------
> >  include/linux/cma.h                                |   6 +-
> >  mm/cma.c                                           |  25 +-
> >  mm/cma.h                                           |   1 +
> >  mm/cma_debug.c                                     |   2 +-
> >  25 files changed, 312 insertions(+), 958 deletions(-)
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile
> >  delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c
> >  delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c
> >  create mode 100644 drivers/staging/android/ion/ion_enumerate.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.c
> >  delete mode 100644 drivers/staging/android/ion/ion_of.h
> >  delete mode 100644 drivers/staging/android/ion/tegra/Makefile
> >  delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/03/2017 05:29 AM, Michal Hocko wrote:
> On Thu 02-03-17 13:44:32, Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works reasonablly well.
>> This series does what should be the final clean ups for it to possibly be
>> moved out of staging.
>>
>> This includes the following:
>> - Some general clean up and removal of features that never got a lot of use
>>   as far as I can tell.
>> - Fixing up the caching. This is the series I proposed back in December[2]
>>   but never heard any feedback on. It will certainly break existing
>>   applications that rely on the implicit caching. I'd rather make an effort
>>   to move to a model that isn't going directly against the establishement
>>   though.
>> - Fixing up the platform support. The devicetree approach was never well
>>   recieved by DT maintainers. The proposal here is to think of Ion less as
>>   specifying requirements and more of a framework for exposing memory to
>>   userspace.
>> - CMA allocations now happen without the need of a dummy device structure.
>>   This fixes a bunch of the reasons why I attempted to add devicetree
>>   support before.
>>
>> I've had problems getting feedback in the past so if I don't hear any major
>> objections I'm going to send out with the RFC dropped to be picked up.
>> The only reason there isn't a patch to come out of staging is to discuss any
>> other changes to the ABI people might want. Once this comes out of staging,
>> I really don't want to mess with the ABI.
> 
> Could you recapitulate concerns preventing the code being merged
> normally rather than through the staging tree and how they were
> addressed?
> 

Sorry, I'm really not understanding your question here, can you
clarify?

Thanks,
Laura

Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping

[Laura Abbott]

On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
>> ensure this happens. As a side effect, this lets Ion buffers take
>> advantage of the dma_buf sync ioctls.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>>  drivers/staging/android/ion/ion.c | 101 +++++++++++++++++------------------
>>  1 file changed, 50 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c index ce4adac..a931b30 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
>>  }
>>  EXPORT_SYMBOL(ion_client_destroy);
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> -				       struct device *dev,
>> -				       enum dma_data_direction direction);
>> -
>>  static struct sg_table *dup_sg_table(struct sg_table *table)
>>  {
>>  	struct sg_table *new_table;
>> @@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table
>> *table) return new_table;
>>  }
>>
>> +static void free_duped_table(struct sg_table *table)
>> +{
>> +	sg_free_table(table);
>> +	kfree(table);
>> +}
>> +
>>  static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
>> *attachment, enum dma_data_direction direction)
>>  {
>>  	struct dma_buf *dmabuf = attachment->dmabuf;
>>  	struct ion_buffer *buffer = dmabuf->priv;
>> +	struct sg_table *table;
>> +	int ret;
>> +
>> +	/*
>> +	 * TODO: Need to sync wrt CPU or device completely owning?
>> +	 */
>> +
>> +	table = dup_sg_table(buffer->sg_table);
>>
>> -	ion_buffer_sync_for_device(buffer, attachment->dev, direction);
>> -	return dup_sg_table(buffer->sg_table);
>> +	if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> +			direction)){
>> +		ret = -ENOMEM;
>> +		goto err;
>> +	}
>> +
>> +err:
>> +	free_duped_table(table);
>> +	return ERR_PTR(ret);
>>  }
>>
>>  static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>>  			      struct sg_table *table,
>>  			      enum dma_data_direction direction)
>>  {
>> -	sg_free_table(table);
>> -	kfree(table);
>> +	dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +	free_duped_table(table);
>>  }
>>
>>  void ion_pages_sync_for_device(struct device *dev, struct page *page,
>> @@ -864,38 +881,6 @@ struct ion_vma_list {
>>  	struct vm_area_struct *vma;
>>  };
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> -				       struct device *dev,
>> -				       enum dma_data_direction dir)
>> -{
>> -	struct ion_vma_list *vma_list;
>> -	int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
>> -	int i;
>> -
>> -	pr_debug("%s: syncing for device %s\n", __func__,
>> -		 dev ? dev_name(dev) : "null");
>> -
>> -	if (!ion_buffer_fault_user_mappings(buffer))
>> -		return;
>> -
>> -	mutex_lock(&buffer->lock);
>> -	for (i = 0; i < pages; i++) {
>> -		struct page *page = buffer->pages[i];
>> -
>> -		if (ion_buffer_page_is_dirty(page))
>> -			ion_pages_sync_for_device(dev, ion_buffer_page(page),
>> -						  PAGE_SIZE, dir);
>> -
>> -		ion_buffer_page_clean(buffer->pages + i);
>> -	}
>> -	list_for_each_entry(vma_list, &buffer->vmas, list) {
>> -		struct vm_area_struct *vma = vma_list->vma;
>> -
>> -		zap_page_range(vma, vma->vm_start, vma->vm_end - vma-
>> vm_start);
>> -	}
>> -	mutex_unlock(&buffer->lock);
>> -}
>> -
>>  static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>>  {
>>  	struct ion_buffer *buffer = vma->vm_private_data;
>> @@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct
>> dma_buf *dmabuf, struct ion_buffer *buffer = dmabuf->priv;
>>  	void *vaddr;
>>
>> -	if (!buffer->heap->ops->map_kernel) {
>> -		pr_err("%s: map kernel is not implemented by this heap.\n",
>> -		       __func__);
>> -		return -ENODEV;
>> +	/*
>> +	 * TODO: Move this elsewhere because we don't always need a vaddr
>> +	 */
>> +	if (buffer->heap->ops->map_kernel) {
>> +		mutex_lock(&buffer->lock);
>> +		vaddr = ion_buffer_kmap_get(buffer);
>> +		mutex_unlock(&buffer->lock);
>>  	}
>>
>> -	mutex_lock(&buffer->lock);
>> -	vaddr = ion_buffer_kmap_get(buffer);
>> -	mutex_unlock(&buffer->lock);
>> -	return PTR_ERR_OR_ZERO(vaddr);
>> +	/*
>> +	 * Close enough right now? Flag to skip sync?
>> +	 */
>> +	if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
>> +			buffer->sg_table->nents,
>> +                        DMA_BIDIRECTIONAL))
> 
> Aren't the dma_(un)map_* calls supposed to take a real, physical device as 
> their first argument ? Beside, this doesn't seem to be the right place to 
> create the mapping, as you mentioned in the commit message the buffer should 
> be mapped in the dma_buf map handler. This is something that needs to be 
> fixed, especially in the light of the comment in ion_buffer_create():
> 

Yes, this might me a case of me getting the model incorrect again.
dma_buf_{begin,end}_cpu_access do not take a device structure and
from the comments:

/**
 * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf from the
 * cpu in the kernel context. Calls begin_cpu_access to allow exporter-specific
 * preparations. Coherency is only guaranteed in the specified range for the
 * specified access direction.
 * @dmabuf:     [in]    buffer to prepare cpu access for.
 * @direction:  [in]    length of range for cpu access.
 *
 * Can return negative error values, returns 0 on success.
 */

If there are no buffer attachments, I guess the notion of 'coherency'
doesn't apply here so there is no need to do any kind of
syncing/mapping at all vs. trying to find a device out of nowhere.

I'll have to go back and re-think aligning sync/begin_cpu_access calls
and dma_buf_map calls, or more likely not overthink this.


>         /*
>          * this will set up dma addresses for the sglist -- it is not
>          * technically correct as per the dma api -- a specific
>          * device isn't really taking ownership here.  However, in practice on
>          * our systems the only dma_address space is physical addresses.
>          * Additionally, we can't afford the overhead of invalidating every
>          * allocation via dma_map_sg. The implicit contract here is that
>          * memory coming from the heaps is ready for dma, ie if it has a
>          * cached mapping that mapping has been invalidated
>          */
> 
> That's a showstopper in my opinion, the DMA address space can't be restricted 
> to physical addresses, IOMMU have to be supported.
> 

I missed a patch in this series to remove that. If Ion is going to exist outside
of staging it should not be making that assumption at all so I want to drop it.
Any performance implications should be fixed with the skip sync flag.

Thanks,
Laura

Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table

[Laura Abbott]

On 03/03/2017 12:18 AM, Hillf Danton wrote:
> 
> On March 03, 2017 5:45 AM Laura Abbott wrote: 
>>
>> +static struct sg_table *dup_sg_table(struct sg_table *table)
>> +{
>> +	struct sg_table *new_table;
>> +	int ret, i;
>> +	struct scatterlist *sg, *new_sg;
>> +
>> +	new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
>> +	if (!new_table)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
>> +	if (ret) {
>> +		kfree(table);
> 
> Free new table?
> 
>> +		return ERR_PTR(-ENOMEM);
>> +	}
>> +
>> +	new_sg = new_table->sgl;
>> +	for_each_sg(table->sgl, sg, table->nents, i) {
>> +		memcpy(new_sg, sg, sizeof(*sg));
>> +		sg->dma_address = 0;
>> +		new_sg = sg_next(new_sg);
>> +	}
>> +
> 
> Do we need a helper, sg_copy_table(dst_table, src_table)?
> 
>> +	return new_table;
>> +}
>> +

Yes, that would probably be good since I've seen this
code elsewhere.

Thanks,
Laura

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laura Abbott]

On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>>> Now that we call dma_map in the dma_buf API callbacks there is no need
>>> to use the existing cache APIs. Remove the sync ioctl and the existing
>>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>>> sync API.
>>>
>>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>>> ---
>>>
>>>  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
>>>  drivers/staging/android/ion/ion.c               | 40 --------------------
>>>  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
>>>  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
>>>  drivers/staging/android/ion/ion_page_pool.c     |  3 --
>>>  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
>>>  6 files changed, 65 deletions(-)
>>>
>>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>>> --- a/drivers/staging/android/ion/ion-ioctl.c
>>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>>> unsigned long arg)> 
>>>  			data.handle.handle = handle->id;
>>>  		
>>>  		break;
>>>  	
>>>  	}
>>>
>>> -	case ION_IOC_SYNC:
>>> -	{
>>> -		ret = ion_sync_for_device(client, data.fd.fd);
>>> -		break;
>>> -	}
>>
>> You missed the case ION_IOC_SYNC: in compat_ion.c.
>>
>> While at it: Should we also remove the entire custom_ioctl infrastructure?
>> It's entirely unused afaict, and for a pure buffer allocator I don't see
>> any need to have custom ioctl.
> 
> I second that, if you want to make ion a standard API, then we certainly don't 
> want any custom ioctl.
> 
>> More code to remove potentially:
>> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>>   would allow us to remove compat_ion.c entirely.
>>
>> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>>   still need to be able to import anything. All the cache flushing/mapping
>>   is done through dma-buf ops/ioctls.
>>
>>

Good point to all of the above. I was considering keeping the import around
for backwards compatibility reasons but given how much other stuff is being
potentially broken, everything should just get ripped out.

Thanks,
Laura

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
>> When CMA was first introduced, its primary use was for DMA allocation
>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>> put Ion in an awkward position since there was no device structure
>> readily available and setting one up messed up the coherency model.
>> These days, CMA can be allocated directly from the APIs. Switch to using
>> this model to avoid needing a dummy device. This also avoids awkward
>> caching questions.
> 
> If the DMA mapping API isn't suitable for today's requirements anymore, I 
> believe that's what needs to be fixed, instead of working around the problem 
> by introducing another use-case-specific API.
> 

I don't think this is a usecase specific API. CMA has been decoupled from
DMA already because it's used in other places. The trying to go through
DMA was just another layer of abstraction, especially since there isn't
a device available for allocation.

Thanks,
Laura

Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable

[Laura Abbott]

On 03/03/2017 02:33 AM, Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
>>
>> Currently, all heaps are compiled in all the time. In switching to
>> a better platform model, let's allow these to be compiled out for good
>> measure.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
> 
> I'm not the biggest fan of making everything Kconfig-selectable. And the
> #ifdef stuff doesn't look all that pretty. If we'd also use this
> opportunity to split each heap into their own file I think this patch here
> would be a lot more useful.
> 
> Anyway, no real opinion from me on this, just an idea.
> -Daniel
> 

My idea with the Kconfigs was that if platforms didn't want certain
heap types (e.g. chunk heap) they could just be turned off.
I do want to fully fix up the initialization better as well.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/03/2017 08:25 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patches.
> 
> On Thursday 02 Mar 2017 13:44:32 Laura Abbott wrote:
>> Hi,
>>
>> There's been some recent discussions[1] about Ion-like frameworks. There's
>> apparently interest in just keeping Ion since it works reasonablly well.
>> This series does what should be the final clean ups for it to possibly be
>> moved out of staging.
>>
>> This includes the following:
>> - Some general clean up and removal of features that never got a lot of use
>>   as far as I can tell.
>> - Fixing up the caching. This is the series I proposed back in December[2]
>>   but never heard any feedback on. It will certainly break existing
>>   applications that rely on the implicit caching. I'd rather make an effort
>>   to move to a model that isn't going directly against the establishement
>>   though.
>> - Fixing up the platform support. The devicetree approach was never well
>>   recieved by DT maintainers. The proposal here is to think of Ion less as
>>   specifying requirements and more of a framework for exposing memory to
>>   userspace.
> 
> That's where most of my concerns with ion are. I still strongly believe that 
> the heap-based approach is inherently flawed, as it would need to be 
> configured for each device according to product-specific use cases. That's not 
> something that could be easily shipped with a generic distribution. We should 
> replace that with a constraint-based system.
> 

I don't think of constraints and heaps as being mutually exclusive. Some general
heaps (e.g. system heaps) can be available always. Others might just be
exposed if there is a particular memory region available. The constraint solving
is responsible for querying and figuring out what's the best choice.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/03/2017 08:45 AM, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote:
>>> Hi,
>>>
>>> There's been some recent discussions[1] about Ion-like frameworks. There's
>>> apparently interest in just keeping Ion since it works reasonablly well.
>>> This series does what should be the final clean ups for it to possibly be
>>> moved out of staging.
>>>
>>> This includes the following:
>>> - Some general clean up and removal of features that never got a lot of
>>>   use as far as I can tell.
>>>
>>> - Fixing up the caching. This is the series I proposed back in December[2]
>>>   but never heard any feedback on. It will certainly break existing
>>>   applications that rely on the implicit caching. I'd rather make an
>>>   effort to move to a model that isn't going directly against the
>>>   establishement though.
>>>
>>> - Fixing up the platform support. The devicetree approach was never well
>>>   recieved by DT maintainers. The proposal here is to think of Ion less as
>>>   specifying requirements and more of a framework for exposing memory to
>>>   userspace.
>>>
>>> - CMA allocations now happen without the need of a dummy device structure.
>>>   This fixes a bunch of the reasons why I attempted to add devicetree
>>>   support before.
>>>
>>> I've had problems getting feedback in the past so if I don't hear any
>>> major objections I'm going to send out with the RFC dropped to be picked
>>> up. The only reason there isn't a patch to come out of staging is to
>>> discuss any other changes to the ABI people might want. Once this comes
>>> out of staging, I really don't want to mess with the ABI.
>>>
>>> Feedback appreciated.
>>
>> Imo looks all good. And I just realized that cross-checking with the TODO,
>> the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there.
>>
>> Otherwise I looked through the patches, looks all really reasonable.
> 
> Two more items that need to be addressed in my opinion :
> 
> - Let's not export the ion_client API, we don't want drivers to be ion-
> specific. Only the dma-buf interface should be visible to drivers.
> 

Yes, that's a good point. I never heard back from anyone about a need for
in kernel allocation via Ion.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Michal Hocko]

On Fri 03-03-17 09:37:55, Laura Abbott wrote:
> On 03/03/2017 05:29 AM, Michal Hocko wrote:
> > On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> >> Hi,
> >>
> >> There's been some recent discussions[1] about Ion-like frameworks. There's
> >> apparently interest in just keeping Ion since it works reasonablly well.
> >> This series does what should be the final clean ups for it to possibly be
> >> moved out of staging.
> >>
> >> This includes the following:
> >> - Some general clean up and removal of features that never got a lot of use
> >>   as far as I can tell.
> >> - Fixing up the caching. This is the series I proposed back in December[2]
> >>   but never heard any feedback on. It will certainly break existing
> >>   applications that rely on the implicit caching. I'd rather make an effort
> >>   to move to a model that isn't going directly against the establishement
> >>   though.
> >> - Fixing up the platform support. The devicetree approach was never well
> >>   recieved by DT maintainers. The proposal here is to think of Ion less as
> >>   specifying requirements and more of a framework for exposing memory to
> >>   userspace.
> >> - CMA allocations now happen without the need of a dummy device structure.
> >>   This fixes a bunch of the reasons why I attempted to add devicetree
> >>   support before.
> >>
> >> I've had problems getting feedback in the past so if I don't hear any major
> >> objections I'm going to send out with the RFC dropped to be picked up.
> >> The only reason there isn't a patch to come out of staging is to discuss any
> >> other changes to the ABI people might want. Once this comes out of staging,
> >> I really don't want to mess with the ABI.
> > 
> > Could you recapitulate concerns preventing the code being merged
> > normally rather than through the staging tree and how they were
> > addressed?
> > 
> 
> Sorry, I'm really not understanding your question here, can you
> clarify?

There must have been a reason why this code ended up in the staging
tree, right? So my question is what those reasons were and how they were
handled in order to move the code from the staging subtree.
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Daniel Vetter]

On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> > Hi Daniel,
> > 
> > On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> >> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> >>> Now that we call dma_map in the dma_buf API callbacks there is no need
> >>> to use the existing cache APIs. Remove the sync ioctl and the existing
> >>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
> >>> sync API.
> >>>
> >>> Signed-off-by: Laura Abbott <labbott@redhat.com>
> >>> ---
> >>>
> >>>  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
> >>>  drivers/staging/android/ion/ion.c               | 40 --------------------
> >>>  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
> >>>  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
> >>>  drivers/staging/android/ion/ion_page_pool.c     |  3 --
> >>>  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
> >>>  6 files changed, 65 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
> >>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
> >>> --- a/drivers/staging/android/ion/ion-ioctl.c
> >>> +++ b/drivers/staging/android/ion/ion-ioctl.c
> >>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> >>> unsigned long arg)> 
> >>>  			data.handle.handle = handle->id;
> >>>  		
> >>>  		break;
> >>>  	
> >>>  	}
> >>>
> >>> -	case ION_IOC_SYNC:
> >>> -	{
> >>> -		ret = ion_sync_for_device(client, data.fd.fd);
> >>> -		break;
> >>> -	}
> >>
> >> You missed the case ION_IOC_SYNC: in compat_ion.c.
> >>
> >> While at it: Should we also remove the entire custom_ioctl infrastructure?
> >> It's entirely unused afaict, and for a pure buffer allocator I don't see
> >> any need to have custom ioctl.
> > 
> > I second that, if you want to make ion a standard API, then we certainly don't 
> > want any custom ioctl.
> > 
> >> More code to remove potentially:
> >> - The entire compat ioctl stuff - would be an abi break, but I guess if we
> >>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
> >>   would allow us to remove compat_ion.c entirely.
> >>
> >> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
> >>   still need to be able to import anything. All the cache flushing/mapping
> >>   is done through dma-buf ops/ioctls.
> >>
> >>
> 
> Good point to all of the above. I was considering keeping the import around
> for backwards compatibility reasons but given how much other stuff is being
> potentially broken, everything should just get ripped out.

If you're ok with breaking the world, then I strongly suggest we go
through the uapi header and replace all types with the standard
fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
the compat ioctl code :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Daniel Vetter]

On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
> On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> > Hi Laura,
> > 
> > Thank you for the patch.
> > 
> > On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> >> When CMA was first introduced, its primary use was for DMA allocation
> >> and the only way to get CMA memory was to call dma_alloc_coherent. This
> >> put Ion in an awkward position since there was no device structure
> >> readily available and setting one up messed up the coherency model.
> >> These days, CMA can be allocated directly from the APIs. Switch to using
> >> this model to avoid needing a dummy device. This also avoids awkward
> >> caching questions.
> > 
> > If the DMA mapping API isn't suitable for today's requirements anymore, I 
> > believe that's what needs to be fixed, instead of working around the problem 
> > by introducing another use-case-specific API.
> > 
> 
> I don't think this is a usecase specific API. CMA has been decoupled from
> DMA already because it's used in other places. The trying to go through
> DMA was just another layer of abstraction, especially since there isn't
> a device available for allocation.

Also, we've had separation of allocation and dma-mapping since forever,
that's how it works almost everywhere. Not exactly sure why/how arm-soc
ecosystem ended up focused so much on dma_alloc_coherent.

I think separating allocation from dma mapping/coherency is perfectly
fine, and the way to go.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> - I haven't seen any proposal how a heap-based solution could be used in a 
> generic distribution. This needs to be figured out before committing to any 
> API/ABI.

Two replies from my side:

- Just because a patch doesn't solve world hunger isn't really a good
  reason to reject it.

- Heap doesn't mean its not resizeable (but I'm not sure that's really
  your concern).

- Imo ION is very much part of the picture here to solve this for real. We
  need to bits:

  * Be able to allocate memory from specific pools, not going through a
    specific driver. ION gives us that interface. This is e.g. also needed
    for "special" memory, like SMA tries to expose.

  * Some way to figure out how&where to allocate the buffer object. This
    is purely a userspace problem, and this is the part the unix memory
    allocator tries to solve. There's no plans in there for big kernel
    changes, instead userspace does a dance to reconcile all the
    constraints, and one of the constraints might be "you have to allocate
    this from this special ION heap". The only thing the kernel needs to
    expose is which devices use which ION heaps (we kinda do that
    already), and maybe some hints of how they can be generalized (but I
    guess stuff like "minimal pagesize of x KB" is also fulfilled by any
    CMA heap is knowledge userspace needs).

Again I think waiting for this to be fully implemented before we merge any
part is going to just kill any upstreaming efforts. ION in itself, without
the full buffer negotiation dance seems clearly useful (also for stuff
like SMA), and having it merged will help with moving the buffer
allocation dance forward.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote:
> On Fri 03-03-17 09:37:55, Laura Abbott wrote:
> > On 03/03/2017 05:29 AM, Michal Hocko wrote:
> > > On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> > >> Hi,
> > >>
> > >> There's been some recent discussions[1] about Ion-like frameworks. There's
> > >> apparently interest in just keeping Ion since it works reasonablly well.
> > >> This series does what should be the final clean ups for it to possibly be
> > >> moved out of staging.
> > >>
> > >> This includes the following:
> > >> - Some general clean up and removal of features that never got a lot of use
> > >>   as far as I can tell.
> > >> - Fixing up the caching. This is the series I proposed back in December[2]
> > >>   but never heard any feedback on. It will certainly break existing
> > >>   applications that rely on the implicit caching. I'd rather make an effort
> > >>   to move to a model that isn't going directly against the establishement
> > >>   though.
> > >> - Fixing up the platform support. The devicetree approach was never well
> > >>   recieved by DT maintainers. The proposal here is to think of Ion less as
> > >>   specifying requirements and more of a framework for exposing memory to
> > >>   userspace.
> > >> - CMA allocations now happen without the need of a dummy device structure.
> > >>   This fixes a bunch of the reasons why I attempted to add devicetree
> > >>   support before.
> > >>
> > >> I've had problems getting feedback in the past so if I don't hear any major
> > >> objections I'm going to send out with the RFC dropped to be picked up.
> > >> The only reason there isn't a patch to come out of staging is to discuss any
> > >> other changes to the ABI people might want. Once this comes out of staging,
> > >> I really don't want to mess with the ABI.
> > > 
> > > Could you recapitulate concerns preventing the code being merged
> > > normally rather than through the staging tree and how they were
> > > addressed?
> > > 
> > 
> > Sorry, I'm really not understanding your question here, can you
> > clarify?
> 
> There must have been a reason why this code ended up in the staging
> tree, right? So my question is what those reasons were and how they were
> handled in order to move the code from the staging subtree.

No one gave a thing about android in upstream, so Greg KH just dumped it
all into staging/android/. We've discussed ION a bunch of times, recorded
anything we'd like to fix in staging/android/TODO, and Laura's patch
series here addresses a big chunk of that.

This is pretty much the same approach we (gpu folks) used to de-stage the
syncpt stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:

> No one gave a thing about android in upstream, so Greg KH just dumped it
> all into staging/android/. We've discussed ION a bunch of times, recorded
> anything we'd like to fix in staging/android/TODO, and Laura's patch
> series here addresses a big chunk of that.

> This is pretty much the same approach we (gpu folks) used to de-stage the
> syncpt stuff.

Well, there's also the fact that quite a few people have issues with the
design (like Laurent).  It seems like a lot of them have either got more
comfortable with it over time, or at least not managed to come up with
any better ideas in the meantime.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Michal Hocko]

On Mon 06-03-17 11:40:41, Daniel Vetter wrote:
> On Mon, Mar 06, 2017 at 08:42:59AM +0100, Michal Hocko wrote:
> > On Fri 03-03-17 09:37:55, Laura Abbott wrote:
> > > On 03/03/2017 05:29 AM, Michal Hocko wrote:
> > > > On Thu 02-03-17 13:44:32, Laura Abbott wrote:
> > > >> Hi,
> > > >>
> > > >> There's been some recent discussions[1] about Ion-like frameworks. There's
> > > >> apparently interest in just keeping Ion since it works reasonablly well.
> > > >> This series does what should be the final clean ups for it to possibly be
> > > >> moved out of staging.
> > > >>
> > > >> This includes the following:
> > > >> - Some general clean up and removal of features that never got a lot of use
> > > >>   as far as I can tell.
> > > >> - Fixing up the caching. This is the series I proposed back in December[2]
> > > >>   but never heard any feedback on. It will certainly break existing
> > > >>   applications that rely on the implicit caching. I'd rather make an effort
> > > >>   to move to a model that isn't going directly against the establishement
> > > >>   though.
> > > >> - Fixing up the platform support. The devicetree approach was never well
> > > >>   recieved by DT maintainers. The proposal here is to think of Ion less as
> > > >>   specifying requirements and more of a framework for exposing memory to
> > > >>   userspace.
> > > >> - CMA allocations now happen without the need of a dummy device structure.
> > > >>   This fixes a bunch of the reasons why I attempted to add devicetree
> > > >>   support before.
> > > >>
> > > >> I've had problems getting feedback in the past so if I don't hear any major
> > > >> objections I'm going to send out with the RFC dropped to be picked up.
> > > >> The only reason there isn't a patch to come out of staging is to discuss any
> > > >> other changes to the ABI people might want. Once this comes out of staging,
> > > >> I really don't want to mess with the ABI.
> > > > 
> > > > Could you recapitulate concerns preventing the code being merged
> > > > normally rather than through the staging tree and how they were
> > > > addressed?
> > > > 
> > > 
> > > Sorry, I'm really not understanding your question here, can you
> > > clarify?
> > 
> > There must have been a reason why this code ended up in the staging
> > tree, right? So my question is what those reasons were and how they were
> > handled in order to move the code from the staging subtree.
> 
> No one gave a thing about android in upstream, so Greg KH just dumped it
> all into staging/android/. We've discussed ION a bunch of times, recorded
> anything we'd like to fix in staging/android/TODO, and Laura's patch
> series here addresses a big chunk of that.

Thanks for the TODO reference. I was looking exactly at something like
that in drivers/staging/android/ion/. To bad I didn't look one directory
up.

Thanks for the clarification!

-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laurent Pinchart]

Hi Daniel,

On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
> On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
> > On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> >>> When CMA was first introduced, its primary use was for DMA allocation
> >>> and the only way to get CMA memory was to call dma_alloc_coherent. This
> >>> put Ion in an awkward position since there was no device structure
> >>> readily available and setting one up messed up the coherency model.
> >>> These days, CMA can be allocated directly from the APIs. Switch to
> >>> using this model to avoid needing a dummy device. This also avoids
> >>> awkward caching questions.
> >> 
> >> If the DMA mapping API isn't suitable for today's requirements anymore,
> >> I believe that's what needs to be fixed, instead of working around the
> >> problem by introducing another use-case-specific API.
> > 
> > I don't think this is a usecase specific API. CMA has been decoupled from
> > DMA already because it's used in other places. The trying to go through
> > DMA was just another layer of abstraction, especially since there isn't
> > a device available for allocation.
> 
> Also, we've had separation of allocation and dma-mapping since forever,
> that's how it works almost everywhere. Not exactly sure why/how arm-soc
> ecosystem ended up focused so much on dma_alloc_coherent.

I believe because that was the easy way to specify memory constraints. The API 
receives a device pointer and will allocate memory suitable for DMA for that 
device. The fact that it maps it to the device is a side-effect in my opinion.

> I think separating allocation from dma mapping/coherency is perfectly
> fine, and the way to go.

Especially given that in many cases we'll want to share buffers between 
multiple devices, so we'll need to map them multiple times.

My point still stands though, if we want to move towards a model where 
allocation and mapping are decoupled, we need an allocation function that 
takes constraints (possibly implemented with two layers, a constraint 
resolution layer on top of a pool/heap/type/foo-based allocator), and a 
mapping API. IOMMU handling being integrated in the DMA mapping API we're 
currently stuck with it, which might call for brushing up that API.

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laurent Pinchart]

Hi Daniel,

On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote:
> On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> > - I haven't seen any proposal how a heap-based solution could be used in a
> > generic distribution. This needs to be figured out before committing to
> > any API/ABI.
> 
> Two replies from my side:
> 
> - Just because a patch doesn't solve world hunger isn't really a good
>   reason to reject it.

As long as it goes in the right direction, sure :-) The points I mentioned 
were to be interpreted that way, I want to make sure we're not going in a 
dead-end (or worse, driving full speed into a wall).

> - Heap doesn't mean its not resizeable (but I'm not sure that's really
>   your concern).

Not really, no. Heap is another word to mean pool here. It might not be the 
best term in this context as it has a precise meaning in the context of memory 
allocation, but that's a detail.

> - Imo ION is very much part of the picture here to solve this for real. We
>   need to bits:
> 
>   * Be able to allocate memory from specific pools, not going through a
>     specific driver. ION gives us that interface. This is e.g. also needed
>     for "special" memory, like SMA tries to expose.
> 
>   * Some way to figure out how&where to allocate the buffer object. This
>     is purely a userspace problem, and this is the part the unix memory
>     allocator tries to solve. There's no plans in there for big kernel
>     changes, instead userspace does a dance to reconcile all the
>     constraints, and one of the constraints might be "you have to allocate
>     this from this special ION heap". The only thing the kernel needs to
>     expose is which devices use which ION heaps (we kinda do that
>     already), and maybe some hints of how they can be generalized (but I
>     guess stuff like "minimal pagesize of x KB" is also fulfilled by any
>     CMA heap is knowledge userspace needs).

The constraint solver could live in userspace, I'm open to a solution that 
would go in that direction, but it will require help from the kernel to fetch 
the constraints from the devices that need to be involved in buffer sharing.

Given a userspace constraint resolver, the interface with the kernel allocator 
will likely be based on pools. I'm not opposed to that, as long as pool are 
identified by opaque handles. I don't want userspace to know about the meaning 
of any particular ION heap. Application must not attempt to "allocate from 
CMA" for instance, that would lock us to a crazy API that will grow completely 
out of hands as vendors will start adding all kind of custom heaps, and 
applications will have to follow (or will be patched out-of-tree by vendors).

> Again I think waiting for this to be fully implemented before we merge any
> part is going to just kill any upstreaming efforts. ION in itself, without
> the full buffer negotiation dance seems clearly useful (also for stuff
> like SMA), and having it merged will help with moving the buffer
> allocation dance forward.

Again I'm not opposed to a kernel allocator based on pools/heaps, as long as

- pools/heaps stay internal to the kernel and are not directly exposed to 
userspace

- a reasonable way to size the different kinds of pools in a generic 
distribution kernel can be found

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Daniel Vetter]

On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
> > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
> > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
> > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> > >>> When CMA was first introduced, its primary use was for DMA allocation
> > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This
> > >>> put Ion in an awkward position since there was no device structure
> > >>> readily available and setting one up messed up the coherency model.
> > >>> These days, CMA can be allocated directly from the APIs. Switch to
> > >>> using this model to avoid needing a dummy device. This also avoids
> > >>> awkward caching questions.
> > >> 
> > >> If the DMA mapping API isn't suitable for today's requirements anymore,
> > >> I believe that's what needs to be fixed, instead of working around the
> > >> problem by introducing another use-case-specific API.
> > > 
> > > I don't think this is a usecase specific API. CMA has been decoupled from
> > > DMA already because it's used in other places. The trying to go through
> > > DMA was just another layer of abstraction, especially since there isn't
> > > a device available for allocation.
> > 
> > Also, we've had separation of allocation and dma-mapping since forever,
> > that's how it works almost everywhere. Not exactly sure why/how arm-soc
> > ecosystem ended up focused so much on dma_alloc_coherent.
> 
> I believe because that was the easy way to specify memory constraints. The API 
> receives a device pointer and will allocate memory suitable for DMA for that 
> device. The fact that it maps it to the device is a side-effect in my opinion.
> 
> > I think separating allocation from dma mapping/coherency is perfectly
> > fine, and the way to go.
> 
> Especially given that in many cases we'll want to share buffers between 
> multiple devices, so we'll need to map them multiple times.
> 
> My point still stands though, if we want to move towards a model where 
> allocation and mapping are decoupled, we need an allocation function that 
> takes constraints (possibly implemented with two layers, a constraint 
> resolution layer on top of a pool/heap/type/foo-based allocator), and a 
> mapping API. IOMMU handling being integrated in the DMA mapping API we're 
> currently stuck with it, which might call for brushing up that API.

Hm, maybe I wasn't clear, but that's exactly what I assume will happen:

The constraint resolver is the unix device memory allocation thing, which
happens entirely in userspace. There's a lot more than just "where to
allocate" to negotiate, e.g. pixel format, stride/size
limits/requirements, tiling formats. A lot of it the kernel doesn't even
know.

Allocation then needs to happen through the kernel ofc, but that doesn't
mean we need to have all the constraint resolving in the kernel. As long
as the kernel exposes the device /dev node -> ion heap stuff, userspace
can figure this out. Or an alternative way would be to have a cascade of
ion heaps to keep things a notch more opaque. Either way, no actaul
constraint resolving in the kernel itself, and except for a bunch more
stuff in sysfs maybe, also no other uapi changes. Once we have a place to
allocate stuff which isn't the device driver at least, aka ION.

And then once allocated you use the dma apis to instantiate the iommus
mappings.

Anyway, at least from my understanding I think there's 0 risk with merging
ION wrt the constraint resolving side (at least as discussed around XDC
last year), and for setups that need cma, it might finally enable to get
things moving forward.

Or do I miss something big here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Mon, Mar 06, 2017 at 05:02:05PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Monday 06 Mar 2017 11:38:20 Daniel Vetter wrote:
> > On Fri, Mar 03, 2017 at 06:45:40PM +0200, Laurent Pinchart wrote:
> > > - I haven't seen any proposal how a heap-based solution could be used in a
> > > generic distribution. This needs to be figured out before committing to
> > > any API/ABI.
> > 
> > Two replies from my side:
> > 
> > - Just because a patch doesn't solve world hunger isn't really a good
> >   reason to reject it.
> 
> As long as it goes in the right direction, sure :-) The points I mentioned 
> were to be interpreted that way, I want to make sure we're not going in a 
> dead-end (or worse, driving full speed into a wall).
> 
> > - Heap doesn't mean its not resizeable (but I'm not sure that's really
> >   your concern).
> 
> Not really, no. Heap is another word to mean pool here. It might not be the 
> best term in this context as it has a precise meaning in the context of memory 
> allocation, but that's a detail.
> 
> > - Imo ION is very much part of the picture here to solve this for real. We
> >   need to bits:
> > 
> >   * Be able to allocate memory from specific pools, not going through a
> >     specific driver. ION gives us that interface. This is e.g. also needed
> >     for "special" memory, like SMA tries to expose.
> > 
> >   * Some way to figure out how&where to allocate the buffer object. This
> >     is purely a userspace problem, and this is the part the unix memory
> >     allocator tries to solve. There's no plans in there for big kernel
> >     changes, instead userspace does a dance to reconcile all the
> >     constraints, and one of the constraints might be "you have to allocate
> >     this from this special ION heap". The only thing the kernel needs to
> >     expose is which devices use which ION heaps (we kinda do that
> >     already), and maybe some hints of how they can be generalized (but I
> >     guess stuff like "minimal pagesize of x KB" is also fulfilled by any
> >     CMA heap is knowledge userspace needs).
> 
> The constraint solver could live in userspace, I'm open to a solution that 
> would go in that direction, but it will require help from the kernel to fetch 
> the constraints from the devices that need to be involved in buffer sharing.
> 
> Given a userspace constraint resolver, the interface with the kernel allocator 
> will likely be based on pools. I'm not opposed to that, as long as pool are 
> identified by opaque handles. I don't want userspace to know about the meaning 
> of any particular ION heap. Application must not attempt to "allocate from 
> CMA" for instance, that would lock us to a crazy API that will grow completely 
> out of hands as vendors will start adding all kind of custom heaps, and 
> applications will have to follow (or will be patched out-of-tree by vendors).
> 
> > Again I think waiting for this to be fully implemented before we merge any
> > part is going to just kill any upstreaming efforts. ION in itself, without
> > the full buffer negotiation dance seems clearly useful (also for stuff
> > like SMA), and having it merged will help with moving the buffer
> > allocation dance forward.
> 
> Again I'm not opposed to a kernel allocator based on pools/heaps, as long as
> 
> - pools/heaps stay internal to the kernel and are not directly exposed to 
> userspace

Agreed (and I think ION doesn't have fixed pools afaik, just kinda
conventions, at least after Laura's patches). But on a fixed board with a
fixed DT (for the cma regions) and fixed .config (for the generic heaps)
you can hardcode your heaps. You'll make your code non-portable, but hey
that's not our problem imo. E.g. board-specific code can also hard-code
how to wire connectors and which one is which in kms (and I've seen this).
I don't think the possibility of abusing the uabi should be a good reason
to prevent it from merging. Anything that provides something with indirect
connections can be abused by hardcoding the names or the indizes.

We do have a TODO entry that talks about exposing the device -> cma heap
link in sysfs or somewhere. I'm not versed enough to know whether Laura's
patches fixed that, this here mostly seems to tackle the fundamentals of
the dma api abuse first.

> - a reasonable way to size the different kinds of pools in a generic 
> distribution kernel can be found

So for the CMA heaps, you can't resize them at runtime, for obvious
reasons. For boot-time you can adjust them through DT, and I thought
everyone agreed that for different use-cases you might need to adjust your
reserved regions.

For all other heaps, they just use the normal allocator functions
(e.g. alloc_pages). There's not limit on those except OOM, so nothing to
adjust really.

I guess I'm still not entirely clear on your "memory pool" concern ... If
it's just the word, we have lots of auto-resizing heaps/pools all around.
And if it's just sizing, I think that's already solved as good as possible
(assuming there's not a silly limit on the system heap that we should
remove ...).

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
> 
> > No one gave a thing about android in upstream, so Greg KH just dumped it
> > all into staging/android/. We've discussed ION a bunch of times, recorded
> > anything we'd like to fix in staging/android/TODO, and Laura's patch
> > series here addresses a big chunk of that.
> 
> > This is pretty much the same approach we (gpu folks) used to de-stage the
> > syncpt stuff.
> 
> Well, there's also the fact that quite a few people have issues with the
> design (like Laurent).  It seems like a lot of them have either got more
> comfortable with it over time, or at least not managed to come up with
> any better ideas in the meantime.

See the TODO, it has everything a really big group (look at the patch for
the full Cc: list) figured needs to be improved at LPC 2015. We don't just
merge stuff because merging stuff is fun :-)

Laurent was even in that group ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Emil Velikov]

On 6 March 2017 at 10:29, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
>> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
>> > Hi Daniel,
>> >
>> > On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> >> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>> >>> Now that we call dma_map in the dma_buf API callbacks there is no need
>> >>> to use the existing cache APIs. Remove the sync ioctl and the existing
>> >>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>> >>> sync API.
>> >>>
>> >>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> >>> ---
>> >>>
>> >>>  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
>> >>>  drivers/staging/android/ion/ion.c               | 40 --------------------
>> >>>  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
>> >>>  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
>> >>>  drivers/staging/android/ion/ion_page_pool.c     |  3 --
>> >>>  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
>> >>>  6 files changed, 65 deletions(-)
>> >>>
>> >>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>> >>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>> >>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> >>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> >>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>> >>> unsigned long arg)>
>> >>>                   data.handle.handle = handle->id;
>> >>>
>> >>>           break;
>> >>>
>> >>>   }
>> >>>
>> >>> - case ION_IOC_SYNC:
>> >>> - {
>> >>> -         ret = ion_sync_for_device(client, data.fd.fd);
>> >>> -         break;
>> >>> - }
>> >>
>> >> You missed the case ION_IOC_SYNC: in compat_ion.c.
>> >>
>> >> While at it: Should we also remove the entire custom_ioctl infrastructure?
>> >> It's entirely unused afaict, and for a pure buffer allocator I don't see
>> >> any need to have custom ioctl.
>> >
>> > I second that, if you want to make ion a standard API, then we certainly don't
>> > want any custom ioctl.
>> >
>> >> More code to remove potentially:
>> >> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>> >>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>> >>   would allow us to remove compat_ion.c entirely.
>> >>
>> >> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>> >>   still need to be able to import anything. All the cache flushing/mapping
>> >>   is done through dma-buf ops/ioctls.
>> >>
>> >>
>>
>> Good point to all of the above. I was considering keeping the import around
>> for backwards compatibility reasons but given how much other stuff is being
>> potentially broken, everything should just get ripped out.
>
> If you're ok with breaking the world, then I strongly suggest we go
> through the uapi header and replace all types with the standard
> fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
> the compat ioctl code :-)

I think the other comments from your "botching-up ioctls" [1] also apply ;-)
Namely - align structs to multiple of 64bit, add "flags" and properly
verity user input returning -EINVAL.

-Emil

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt

Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly

[Laura Abbott]

On 03/06/2017 07:52 AM, Daniel Vetter wrote:
> On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote:
>>> On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote:
>>>> On 03/03/2017 08:41 AM, Laurent Pinchart wrote:
>>>>> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
>>>>>> When CMA was first introduced, its primary use was for DMA allocation
>>>>>> and the only way to get CMA memory was to call dma_alloc_coherent. This
>>>>>> put Ion in an awkward position since there was no device structure
>>>>>> readily available and setting one up messed up the coherency model.
>>>>>> These days, CMA can be allocated directly from the APIs. Switch to
>>>>>> using this model to avoid needing a dummy device. This also avoids
>>>>>> awkward caching questions.
>>>>>
>>>>> If the DMA mapping API isn't suitable for today's requirements anymore,
>>>>> I believe that's what needs to be fixed, instead of working around the
>>>>> problem by introducing another use-case-specific API.
>>>>
>>>> I don't think this is a usecase specific API. CMA has been decoupled from
>>>> DMA already because it's used in other places. The trying to go through
>>>> DMA was just another layer of abstraction, especially since there isn't
>>>> a device available for allocation.
>>>
>>> Also, we've had separation of allocation and dma-mapping since forever,
>>> that's how it works almost everywhere. Not exactly sure why/how arm-soc
>>> ecosystem ended up focused so much on dma_alloc_coherent.
>>
>> I believe because that was the easy way to specify memory constraints. The API 
>> receives a device pointer and will allocate memory suitable for DMA for that 
>> device. The fact that it maps it to the device is a side-effect in my opinion.
>>

Agreed. The device Ion wanted to use was never a real device though
so any constraints it satisfied were making assumptions about what
memory would be allocated.


>>> I think separating allocation from dma mapping/coherency is perfectly
>>> fine, and the way to go.
>>
>> Especially given that in many cases we'll want to share buffers between 
>> multiple devices, so we'll need to map them multiple times.
>>
>> My point still stands though, if we want to move towards a model where 
>> allocation and mapping are decoupled, we need an allocation function that 
>> takes constraints (possibly implemented with two layers, a constraint 
>> resolution layer on top of a pool/heap/type/foo-based allocator), and a 
>> mapping API. IOMMU handling being integrated in the DMA mapping API we're 
>> currently stuck with it, which might call for brushing up that API.
> 
> Hm, maybe I wasn't clear, but that's exactly what I assume will happen:
> 
> The constraint resolver is the unix device memory allocation thing, which
> happens entirely in userspace. There's a lot more than just "where to
> allocate" to negotiate, e.g. pixel format, stride/size
> limits/requirements, tiling formats. A lot of it the kernel doesn't even
> know.
> 
> Allocation then needs to happen through the kernel ofc, but that doesn't
> mean we need to have all the constraint resolving in the kernel. As long
> as the kernel exposes the device /dev node -> ion heap stuff, userspace
> can figure this out. Or an alternative way would be to have a cascade of
> ion heaps to keep things a notch more opaque. Either way, no actaul
> constraint resolving in the kernel itself, and except for a bunch more
> stuff in sysfs maybe, also no other uapi changes. Once we have a place to
> allocate stuff which isn't the device driver at least, aka ION.
> 
> And then once allocated you use the dma apis to instantiate the iommus
> mappings.
> 
> Anyway, at least from my understanding I think there's 0 risk with merging
> ION wrt the constraint resolving side (at least as discussed around XDC
> last year), and for setups that need cma, it might finally enable to get
> things moving forward.
> 
> Or do I miss something big here?
> -Daniel
> 

This all sounds like what I was thinking. I think some of the concerns
may be that the details of constraint solving are mostly handwaving
right now.

Thanks,
Laura

Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support

[Laura Abbott]

On 03/06/2017 09:00 AM, Emil Velikov wrote:
> On 6 March 2017 at 10:29, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Fri, Mar 03, 2017 at 10:46:03AM -0800, Laura Abbott wrote:
>>> On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
>>>> Hi Daniel,
>>>>
>>>> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>>>>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>>>>>> Now that we call dma_map in the dma_buf API callbacks there is no need
>>>>>> to use the existing cache APIs. Remove the sync ioctl and the existing
>>>>>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>>>>>> sync API.
>>>>>>
>>>>>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>>>>>> ---
>>>>>>
>>>>>>  drivers/staging/android/ion/ion-ioctl.c         |  5 ----
>>>>>>  drivers/staging/android/ion/ion.c               | 40 --------------------
>>>>>>  drivers/staging/android/ion/ion_carveout_heap.c |  6 ----
>>>>>>  drivers/staging/android/ion/ion_chunk_heap.c    |  6 ----
>>>>>>  drivers/staging/android/ion/ion_page_pool.c     |  3 --
>>>>>>  drivers/staging/android/ion/ion_system_heap.c   |  5 ----
>>>>>>  6 files changed, 65 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>>>>>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>>>>>> --- a/drivers/staging/android/ion/ion-ioctl.c
>>>>>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>>>>>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>>>>>> unsigned long arg)>
>>>>>>                   data.handle.handle = handle->id;
>>>>>>
>>>>>>           break;
>>>>>>
>>>>>>   }
>>>>>>
>>>>>> - case ION_IOC_SYNC:
>>>>>> - {
>>>>>> -         ret = ion_sync_for_device(client, data.fd.fd);
>>>>>> -         break;
>>>>>> - }
>>>>>
>>>>> You missed the case ION_IOC_SYNC: in compat_ion.c.
>>>>>
>>>>> While at it: Should we also remove the entire custom_ioctl infrastructure?
>>>>> It's entirely unused afaict, and for a pure buffer allocator I don't see
>>>>> any need to have custom ioctl.
>>>>
>>>> I second that, if you want to make ion a standard API, then we certainly don't
>>>> want any custom ioctl.
>>>>
>>>>> More code to remove potentially:
>>>>> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>>>>>   pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>>>>>   would allow us to remove compat_ion.c entirely.
>>>>>
>>>>> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>>>>>   still need to be able to import anything. All the cache flushing/mapping
>>>>>   is done through dma-buf ops/ioctls.
>>>>>
>>>>>
>>>
>>> Good point to all of the above. I was considering keeping the import around
>>> for backwards compatibility reasons but given how much other stuff is being
>>> potentially broken, everything should just get ripped out.
>>
>> If you're ok with breaking the world, then I strongly suggest we go
>> through the uapi header and replace all types with the standard
>> fixed-width ones (__s32, __s64 and __u32, __u64). Allows us to remove all
>> the compat ioctl code :-)
> 
> I think the other comments from your "botching-up ioctls" [1] also apply ;-)
> Namely - align structs to multiple of 64bit, add "flags" and properly
> verity user input returning -EINVAL.
> 
> -Emil
> 
> [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/botching-up-ioctls.txt

I'm more torn on this. There's a difference between dropping an old
ioctl/implicit caching vs. changing an actual ioctl ABI.
Maybe having obvious breakage is better than subtle though,
plus nobody has come begging me not to break the ABI yet.
I might leave this for right before we do the actual move
out of staging.

Thanks,
Laura

 

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>
>> > No one gave a thing about android in upstream, so Greg KH just dumped it
>> > all into staging/android/. We've discussed ION a bunch of times, recorded
>> > anything we'd like to fix in staging/android/TODO, and Laura's patch
>> > series here addresses a big chunk of that.
>>
>> > This is pretty much the same approach we (gpu folks) used to de-stage the
>> > syncpt stuff.
>>
>> Well, there's also the fact that quite a few people have issues with the
>> design (like Laurent).  It seems like a lot of them have either got more
>> comfortable with it over time, or at least not managed to come up with
>> any better ideas in the meantime.
>
> See the TODO, it has everything a really big group (look at the patch for
> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
> merge stuff because merging stuff is fun :-)
>
> Laurent was even in that group ...
> -Daniel

For me those patches are going in the right direction.

I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed from ioctl structure ?
- can you we ride off ion_handle (at least in userland) and only
export a dma-buf descriptor ?

In the future how can we add new heaps ?
Some platforms have very specific memory allocation
requirements (just have a look in the number of gem custom allocator in drm)
Do you plan to add heap type/mask for each ?

Benjamin

> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch


Follow Linaro: Facebook | Twitter | Blog

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>
>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>> series here addresses a big chunk of that.
>>>
>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>> syncpt stuff.
>>>
>>> Well, there's also the fact that quite a few people have issues with the
>>> design (like Laurent).  It seems like a lot of them have either got more
>>> comfortable with it over time, or at least not managed to come up with
>>> any better ideas in the meantime.
>>
>> See the TODO, it has everything a really big group (look at the patch for
>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>> merge stuff because merging stuff is fun :-)
>>
>> Laurent was even in that group ...
>> -Daniel
> 
> For me those patches are going in the right direction.
> 
> I still have few questions:
> - since alignment management has been remove from ion-core, should it
> be also removed from ioctl structure ?

Yes, I think I'm going to go with the suggestion to fixup the ABI
so we don't need the compat layer and as part of that I'm also
dropping the align argument.

> - can you we ride off ion_handle (at least in userland) and only
> export a dma-buf descriptor ?

Yes, I think this is the right direction given we're breaking
everything anyway. I was debating trying to keep the two but
moving to only dma bufs is probably cleaner. The only reason
I could see for keeping the handles is running out of file
descriptors for dma-bufs but that seems unlikely.
> 
> In the future how can we add new heaps ?
> Some platforms have very specific memory allocation
> requirements (just have a look in the number of gem custom allocator in drm)
> Do you plan to add heap type/mask for each ?

Yes, that was my thinking. 

> 
> Benjamin
> 

Thanks,
Laura

Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

[Sumit Semwal]

Hi Laura,

Thanks for the patch.

On 3 March 2017 at 03:14, Laura Abbott <labbott@redhat.com> wrote:
>
> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
> useful to have an explicit name attached to each region. Store the name
> in each CMA structure.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
>  drivers/base/dma-contiguous.c |  5 +++--
>  include/linux/cma.h           |  4 +++-
>  mm/cma.c                      | 11 +++++++++--
>  mm/cma.h                      |  1 +
>  mm/cma_debug.c                |  2 +-
>  5 files changed, 17 insertions(+), 6 deletions(-)
>
<snip>
> +const char *cma_get_name(const struct cma *cma)
> +{
> +       return cma->name ? cma->name : "(undefined)";
> +}
> +
Would it make sense to perhaps have the idx stored as the name,
instead of 'undefined'? That would make sure that the various cma
names are still unique.

>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>                                              int align_order)
>  {
> @@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
>   */
>  int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>                                  unsigned int order_per_bit,
> +                                const char *name,
>                                  struct cma **res_cma)
>  {

Best regards,
Sumit.

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

Hi,

On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:

[snip]

>>
>> For me those patches are going in the right direction.
>>
>> I still have few questions:
>> - since alignment management has been remove from ion-core, should it
>> be also removed from ioctl structure ?
>
>Yes, I think I'm going to go with the suggestion to fixup the ABI
>so we don't need the compat layer and as part of that I'm also
>dropping the align argument.
>

Is the only motivation for removing the alignment parameter that
no-one got around to using it for something useful yet?
The original comment was true - different devices do have different
alignment requirements.

Better alignment can help SMMUs use larger blocks when mapping,
reducing TLB pressure and the chance of a page table walk causing
display underruns.

-Brian

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Robin Murphy]

On 10/03/17 10:31, Brian Starkey wrote:
> Hi,
> 
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 
> [snip]
> 
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignment management has been remove from ion-core, should it
>>> be also removed from ioctl structure ?
>>
>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>> so we don't need the compat layer and as part of that I'm also
>> dropping the align argument.
>>
> 
> Is the only motivation for removing the alignment parameter that
> no-one got around to using it for something useful yet?
> The original comment was true - different devices do have different
> alignment requirements.
> 
> Better alignment can help SMMUs use larger blocks when mapping,
> reducing TLB pressure and the chance of a page table walk causing
> display underruns.

For that use-case, though, alignment alone doesn't necessarily help -
you need the whole allocation granularity to match your block size (i.e.
given a 1MB block size, asking for 17KB and getting back 17KB starting
at a 1MB boundary doesn't help much - that whole 1MB needs to be
allocated and everyone needs to know it to ensure that the whole lot can
be mapped safely). Now, whether it's down to the callers or the heap
implementations to decide and enforce that granularity is another
question, but provided allocations are at least naturally aligned to
whatever the granularity is (which is a reasonable assumption to bake
in) then it's all good.

Robin.

> 
> -Brian
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Fri, Mar 10, 2017 at 10:31:13AM +0000, Brian Starkey wrote:
> Hi,
> 
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 
> [snip]
> 
> > > 
> > > For me those patches are going in the right direction.
> > > 
> > > I still have few questions:
> > > - since alignment management has been remove from ion-core, should it
> > > be also removed from ioctl structure ?
> > 
> > Yes, I think I'm going to go with the suggestion to fixup the ABI
> > so we don't need the compat layer and as part of that I'm also
> > dropping the align argument.
> > 
> 
> Is the only motivation for removing the alignment parameter that
> no-one got around to using it for something useful yet?
> The original comment was true - different devices do have different
> alignment requirements.
> 
> Better alignment can help SMMUs use larger blocks when mapping,
> reducing TLB pressure and the chance of a page table walk causing
> display underruns.

Extending ioctl uapi is easy, trying to get rid of bad uapi is much
harder. Given that right now we don't have an ion allocator that does
alignment I think removing it makes sense. And if we go with lots of
heaps, we might as well have an ion heap per alignment that your hw needs,
so there's different ways to implement this in the future.

At least from the unix device memory allocator pov it's probably simpler
to encode stuff like this into the heap name, instead of having to pass
heap + list of additional properties/constraints.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Rob Clark]

On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Mar 10, 2017 at 10:31:13AM +0000, Brian Starkey wrote:
>> Hi,
>>
>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>
>> [snip]
>>
>> > >
>> > > For me those patches are going in the right direction.
>> > >
>> > > I still have few questions:
>> > > - since alignment management has been remove from ion-core, should it
>> > > be also removed from ioctl structure ?
>> >
>> > Yes, I think I'm going to go with the suggestion to fixup the ABI
>> > so we don't need the compat layer and as part of that I'm also
>> > dropping the align argument.
>> >
>>
>> Is the only motivation for removing the alignment parameter that
>> no-one got around to using it for something useful yet?
>> The original comment was true - different devices do have different
>> alignment requirements.
>>
>> Better alignment can help SMMUs use larger blocks when mapping,
>> reducing TLB pressure and the chance of a page table walk causing
>> display underruns.
>
> Extending ioctl uapi is easy, trying to get rid of bad uapi is much
> harder. Given that right now we don't have an ion allocator that does
> alignment I think removing it makes sense. And if we go with lots of
> heaps, we might as well have an ion heap per alignment that your hw needs,
> so there's different ways to implement this in the future.

slight correction:  if you plan ahead (and do things like zero init if
userspace passes in a smaller ioctl struct like drm_ioctl does),
extending ioctl uapi is easy.. might be something worth fixing from
the get-go..

BR,
-R

> At least from the unix device memory allocator pov it's probably simpler
> to encode stuff like this into the heap name, instead of having to pass
> heap + list of additional properties/constraints.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

On Fri, Mar 10, 2017 at 11:46:42AM +0000, Robin Murphy wrote:
>On 10/03/17 10:31, Brian Starkey wrote:
>> Hi,
>>
>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>
>> [snip]
>>
>>>>
>>>> For me those patches are going in the right direction.
>>>>
>>>> I still have few questions:
>>>> - since alignment management has been remove from ion-core, should it
>>>> be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
>>
>> Is the only motivation for removing the alignment parameter that
>> no-one got around to using it for something useful yet?
>> The original comment was true - different devices do have different
>> alignment requirements.
>>
>> Better alignment can help SMMUs use larger blocks when mapping,
>> reducing TLB pressure and the chance of a page table walk causing
>> display underruns.
>
>For that use-case, though, alignment alone doesn't necessarily help -
>you need the whole allocation granularity to match your block size (i.e.
>given a 1MB block size, asking for 17KB and getting back 17KB starting
>at a 1MB boundary doesn't help much - that whole 1MB needs to be
>allocated and everyone needs to know it to ensure that the whole lot can
>be mapped safely). Now, whether it's down to the callers or the heap
>implementations to decide and enforce that granularity is another
>question, but provided allocations are at least naturally aligned to
>whatever the granularity is (which is a reasonable assumption to bake
>in) then it's all good.
>
>Robin.

Agreed, alignment alone isn't enough. But lets assume that an app
knows what a "good" granularity is, and always asks for allocation
sizes which are suitably rounded to allow blocks to be used. Currently
it looks like a "standard" ION_HEAP_TYPE_CARVEOUT heap would give me
back just a PAGE_SIZE aligned buffer. So even *if* the caller knows
its desired block size, there's no way for it to get guaranteed better
alignment, which wouldn't be a bad feature to have.

Anyway as Daniel and Rob say, if the interface is designed properly
this kind of extension would be possible later, or you can have a
special heap with a larger granule.

I suppose it makes sense to remove it while there's no-one actually
implementing it, in case an alternate method proves more usable.

-Brian

>
>>
>> -Brian
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/10/2017 06:27 AM, Brian Starkey wrote:
> On Fri, Mar 10, 2017 at 11:46:42AM +0000, Robin Murphy wrote:
>> On 10/03/17 10:31, Brian Starkey wrote:
>>> Hi,
>>>
>>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>
>>> [snip]
>>>
>>>>>
>>>>> For me those patches are going in the right direction.
>>>>>
>>>>> I still have few questions:
>>>>> - since alignment management has been remove from ion-core, should it
>>>>> be also removed from ioctl structure ?
>>>>
>>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>>> so we don't need the compat layer and as part of that I'm also
>>>> dropping the align argument.
>>>>
>>>
>>> Is the only motivation for removing the alignment parameter that
>>> no-one got around to using it for something useful yet?
>>> The original comment was true - different devices do have different
>>> alignment requirements.
>>>
>>> Better alignment can help SMMUs use larger blocks when mapping,
>>> reducing TLB pressure and the chance of a page table walk causing
>>> display underruns.
>>
>> For that use-case, though, alignment alone doesn't necessarily help -
>> you need the whole allocation granularity to match your block size (i.e.
>> given a 1MB block size, asking for 17KB and getting back 17KB starting
>> at a 1MB boundary doesn't help much - that whole 1MB needs to be
>> allocated and everyone needs to know it to ensure that the whole lot can
>> be mapped safely). Now, whether it's down to the callers or the heap
>> implementations to decide and enforce that granularity is another
>> question, but provided allocations are at least naturally aligned to
>> whatever the granularity is (which is a reasonable assumption to bake
>> in) then it's all good.
>>
>> Robin.
> 
> Agreed, alignment alone isn't enough. But lets assume that an app
> knows what a "good" granularity is, and always asks for allocation
> sizes which are suitably rounded to allow blocks to be used. Currently
> it looks like a "standard" ION_HEAP_TYPE_CARVEOUT heap would give me
> back just a PAGE_SIZE aligned buffer. So even *if* the caller knows
> its desired block size, there's no way for it to get guaranteed better
> alignment, which wouldn't be a bad feature to have.
> 
> Anyway as Daniel and Rob say, if the interface is designed properly
> this kind of extension would be possible later, or you can have a
> special heap with a larger granule.
> 
> I suppose it makes sense to remove it while there's no-one actually
> implementing it, in case an alternate method proves more usable.
> 
> -Brian

Part of the reason I want to remove it is to avoid confusion over
callers thinking it will do anything on most heaps. I agree being
able to specify a larger granularity would be beneficial but I
don't think a dedicated field in the ABI is the right approach.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>
>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>> series here addresses a big chunk of that.
>>>>
>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>> syncpt stuff.
>>>>
>>>> Well, there's also the fact that quite a few people have issues with the
>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>> comfortable with it over time, or at least not managed to come up with
>>>> any better ideas in the meantime.
>>>
>>> See the TODO, it has everything a really big group (look at the patch for
>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>> merge stuff because merging stuff is fun :-)
>>>
>>> Laurent was even in that group ...
>>> -Daniel
>>
>> For me those patches are going in the right direction.
>>
>> I still have few questions:
>> - since alignment management has been remove from ion-core, should it
>> be also removed from ioctl structure ?
>
> Yes, I think I'm going to go with the suggestion to fixup the ABI
> so we don't need the compat layer and as part of that I'm also
> dropping the align argument.
>
>> - can you we ride off ion_handle (at least in userland) and only
>> export a dma-buf descriptor ?
>
> Yes, I think this is the right direction given we're breaking
> everything anyway. I was debating trying to keep the two but
> moving to only dma bufs is probably cleaner. The only reason
> I could see for keeping the handles is running out of file
> descriptors for dma-bufs but that seems unlikely.
>>
>> In the future how can we add new heaps ?
>> Some platforms have very specific memory allocation
>> requirements (just have a look in the number of gem custom allocator in drm)
>> Do you plan to add heap type/mask for each ?
>
> Yes, that was my thinking.

My concern is about the policy to adding heaps, will you accept
"customs" heap per
platforms ? per devices ? or only generic ones ?
If you are too strict, we will have lot of out-of-tree heaps and if
you accept of of them
it will be a nightmare to maintain....

Another point is how can we put secure rules (like selinux policy) on
heaps since all the allocations
go to the same device (/dev/ion) ? For example, until now, in Android
we have to give the same
access rights to all the process that use ION.
It will become problem when we will add secure heaps because we won't
be able to distinguish secure
processes to standard ones or set specific policy per heaps.
Maybe I'm wrong here but I have never see selinux policy checking an
ioctl field but if that
exist it could be a solution.

>
>>
>> Benjamin
>>
>
> Thanks,
> Laura
>

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>
>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>> series here addresses a big chunk of that.
>>>>>
>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>> syncpt stuff.
>>>>>
>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>> comfortable with it over time, or at least not managed to come up with
>>>>> any better ideas in the meantime.
>>>>
>>>> See the TODO, it has everything a really big group (look at the patch for
>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>> merge stuff because merging stuff is fun :-)
>>>>
>>>> Laurent was even in that group ...
>>>> -Daniel
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignment management has been remove from ion-core, should it
>>> be also removed from ioctl structure ?
>>
>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>> so we don't need the compat layer and as part of that I'm also
>> dropping the align argument.
>>
>>> - can you we ride off ion_handle (at least in userland) and only
>>> export a dma-buf descriptor ?
>>
>> Yes, I think this is the right direction given we're breaking
>> everything anyway. I was debating trying to keep the two but
>> moving to only dma bufs is probably cleaner. The only reason
>> I could see for keeping the handles is running out of file
>> descriptors for dma-bufs but that seems unlikely.
>>>
>>> In the future how can we add new heaps ?
>>> Some platforms have very specific memory allocation
>>> requirements (just have a look in the number of gem custom allocator in drm)
>>> Do you plan to add heap type/mask for each ?
>>
>> Yes, that was my thinking.
>
> My concern is about the policy to adding heaps, will you accept
> "customs" heap per
> platforms ? per devices ? or only generic ones ?
> If you are too strict, we will have lot of out-of-tree heaps and if
> you accept of of them
> it will be a nightmare to maintain....

I think ion should expose any heap that's also directly accessible to
devices using dma_alloc(_coherent). That should leave very few things
left, like your SMA heap.

> Another point is how can we put secure rules (like selinux policy) on
> heaps since all the allocations
> go to the same device (/dev/ion) ? For example, until now, in Android
> we have to give the same
> access rights to all the process that use ION.
> It will become problem when we will add secure heaps because we won't
> be able to distinguish secure
> processes to standard ones or set specific policy per heaps.
> Maybe I'm wrong here but I have never see selinux policy checking an
> ioctl field but if that
> exist it could be a solution.

Hm, we might want to expose all the heaps as individual
/dev/ion_$heapname nodes? Should we do this from the start, since
we're massively revamping the uapi anyway (imo not needed, current
state seems to work too)?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
>2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>
>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>> series here addresses a big chunk of that.
>>>>>
>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>> syncpt stuff.
>>>>>
>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>> comfortable with it over time, or at least not managed to come up with
>>>>> any better ideas in the meantime.
>>>>
>>>> See the TODO, it has everything a really big group (look at the patch for
>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>> merge stuff because merging stuff is fun :-)
>>>>
>>>> Laurent was even in that group ...
>>>> -Daniel
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignment management has been remove from ion-core, should it
>>> be also removed from ioctl structure ?
>>
>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>> so we don't need the compat layer and as part of that I'm also
>> dropping the align argument.
>>
>>> - can you we ride off ion_handle (at least in userland) and only
>>> export a dma-buf descriptor ?
>>
>> Yes, I think this is the right direction given we're breaking
>> everything anyway. I was debating trying to keep the two but
>> moving to only dma bufs is probably cleaner. The only reason
>> I could see for keeping the handles is running out of file
>> descriptors for dma-bufs but that seems unlikely.
>>>
>>> In the future how can we add new heaps ?
>>> Some platforms have very specific memory allocation
>>> requirements (just have a look in the number of gem custom allocator in drm)
>>> Do you plan to add heap type/mask for each ?
>>
>> Yes, that was my thinking.
>
>My concern is about the policy to adding heaps, will you accept
>"customs" heap per
>platforms ? per devices ? or only generic ones ?
>If you are too strict, we will have lot of out-of-tree heaps and if
>you accept of of them
>it will be a nightmare to maintain....
>

Are you concerned about actual heaps (e.g. a carveout at 0x80000000 vs
a carveout at 0x60000000) or heap types?

For heap types, I think the policy can be strict - if it's generally
useful then it should live in-tree in ion. Otherwise, it would be
out-of-tree. I'd expect most "custom" heaps to be parameterisable to
the point of being generally useful.

For actual heap instances, I would expect them to be communicated via
reserved-memory regions or something similar, and so the maintenance
burden is pretty low.

The existing query ioctl can allow heap IDs to get assigned
dynamically at runtime, so there's no need to reserve "bit 6" for
"CUSTOM_ACME_HEAP_1"

>Another point is how can we put secure rules (like selinux policy) on
>heaps since all the allocations
>go to the same device (/dev/ion) ? For example, until now, in Android
>we have to give the same
>access rights to all the process that use ION.
>It will become problem when we will add secure heaps because we won't
>be able to distinguish secure
>processes to standard ones or set specific policy per heaps.
>Maybe I'm wrong here but I have never see selinux policy checking an
>ioctl field but if that
>exist it could be a solution.
>

I might be thinking of a different type of "secure", but...

Should the security of secure heaps be enforced by OS-level
permissions? I don't know about other architectures, but at least on
arm/arm64 this is enforced in hardware; it doesn't matter who has
access to the ion heap, because only secure devices (or the CPU
running a secure process) is physically able to access the memory
backing the buffer.

In fact, in the use-cases I know of, the process asking for the ion
allocation is not a secure process, and so we wouldn't *want* to
restrict the secure heap to be allocated from only by secure
processes.

-Brian

>>
>>>
>>> Benjamin
>>>
>>
>> Thanks,
>> Laura
>>

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:

> > Another point is how can we put secure rules (like selinux policy) on
> > heaps since all the allocations
> > go to the same device (/dev/ion) ? For example, until now, in Android
> > we have to give the same
> > access rights to all the process that use ION.
> > It will become problem when we will add secure heaps because we won't
> > be able to distinguish secure
> > processes to standard ones or set specific policy per heaps.
> > Maybe I'm wrong here but I have never see selinux policy checking an
> > ioctl field but if that
> > exist it could be a solution.

> I might be thinking of a different type of "secure", but...

> Should the security of secure heaps be enforced by OS-level
> permissions? I don't know about other architectures, but at least on
> arm/arm64 this is enforced in hardware; it doesn't matter who has
> access to the ion heap, because only secure devices (or the CPU
> running a secure process) is physically able to access the memory
> backing the buffer.

> In fact, in the use-cases I know of, the process asking for the ion
> allocation is not a secure process, and so we wouldn't *want* to
> restrict the secure heap to be allocated from only by secure
> processes.

I think there's an orthogonal level of OS level security that can be
applied here - it's reasonable for it to want to say things like "only
processes that are supposed to be implementing functionality X should be
able to try to allocate memory set aside for that functionality".  This
mitigates against escallation attacks and so on, it's not really
directly related to secure memory as such though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/12/2017 12:05 PM, Daniel Vetter wrote:
> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
> <benjamin.gaignard@linaro.org> wrote:
>> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>>
>>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>>> series here addresses a big chunk of that.
>>>>>>
>>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>>> syncpt stuff.
>>>>>>
>>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>>> comfortable with it over time, or at least not managed to come up with
>>>>>> any better ideas in the meantime.
>>>>>
>>>>> See the TODO, it has everything a really big group (look at the patch for
>>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>>> merge stuff because merging stuff is fun :-)
>>>>>
>>>>> Laurent was even in that group ...
>>>>> -Daniel
>>>>
>>>> For me those patches are going in the right direction.
>>>>
>>>> I still have few questions:
>>>> - since alignment management has been remove from ion-core, should it
>>>> be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
>>>> - can you we ride off ion_handle (at least in userland) and only
>>>> export a dma-buf descriptor ?
>>>
>>> Yes, I think this is the right direction given we're breaking
>>> everything anyway. I was debating trying to keep the two but
>>> moving to only dma bufs is probably cleaner. The only reason
>>> I could see for keeping the handles is running out of file
>>> descriptors for dma-bufs but that seems unlikely.
>>>>
>>>> In the future how can we add new heaps ?
>>>> Some platforms have very specific memory allocation
>>>> requirements (just have a look in the number of gem custom allocator in drm)
>>>> Do you plan to add heap type/mask for each ?
>>>
>>> Yes, that was my thinking.
>>
>> My concern is about the policy to adding heaps, will you accept
>> "customs" heap per
>> platforms ? per devices ? or only generic ones ?
>> If you are too strict, we will have lot of out-of-tree heaps and if
>> you accept of of them
>> it will be a nightmare to maintain....
> 
> I think ion should expose any heap that's also directly accessible to
> devices using dma_alloc(_coherent). That should leave very few things
> left, like your SMA heap.
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ? For example, until now, in Android
>> we have to give the same
>> access rights to all the process that use ION.
>> It will become problem when we will add secure heaps because we won't
>> be able to distinguish secure
>> processes to standard ones or set specific policy per heaps.
>> Maybe I'm wrong here but I have never see selinux policy checking an
>> ioctl field but if that
>> exist it could be a solution.
> 
> Hm, we might want to expose all the heaps as individual
> /dev/ion_$heapname nodes? Should we do this from the start, since
> we're massively revamping the uapi anyway (imo not needed, current
> state seems to work too)?
> -Daniel
> 

I thought about that. One advantage with separate /dev/ion_$heap
is that we don't have to worry about a limit of 32 possible
heaps per system (32-bit heap id allocation field). But dealing
with an ioctl seems easier than names. Userspace might be less
likely to hardcode random id numbers vs. names as well.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 03:54 AM, Brian Starkey wrote:
> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
>> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>>
>>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>>> series here addresses a big chunk of that.
>>>>>>
>>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>>> syncpt stuff.
>>>>>>
>>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>>> comfortable with it over time, or at least not managed to come up with
>>>>>> any better ideas in the meantime.
>>>>>
>>>>> See the TODO, it has everything a really big group (look at the patch for
>>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>>> merge stuff because merging stuff is fun :-)
>>>>>
>>>>> Laurent was even in that group ...
>>>>> -Daniel
>>>>
>>>> For me those patches are going in the right direction.
>>>>
>>>> I still have few questions:
>>>> - since alignment management has been remove from ion-core, should it
>>>> be also removed from ioctl structure ?
>>>
>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>> so we don't need the compat layer and as part of that I'm also
>>> dropping the align argument.
>>>
>>>> - can you we ride off ion_handle (at least in userland) and only
>>>> export a dma-buf descriptor ?
>>>
>>> Yes, I think this is the right direction given we're breaking
>>> everything anyway. I was debating trying to keep the two but
>>> moving to only dma bufs is probably cleaner. The only reason
>>> I could see for keeping the handles is running out of file
>>> descriptors for dma-bufs but that seems unlikely.
>>>>
>>>> In the future how can we add new heaps ?
>>>> Some platforms have very specific memory allocation
>>>> requirements (just have a look in the number of gem custom allocator in drm)
>>>> Do you plan to add heap type/mask for each ?
>>>
>>> Yes, that was my thinking.
>>
>> My concern is about the policy to adding heaps, will you accept
>> "customs" heap per
>> platforms ? per devices ? or only generic ones ?
>> If you are too strict, we will have lot of out-of-tree heaps and if
>> you accept of of them
>> it will be a nightmare to maintain....
>>
> 
> Are you concerned about actual heaps (e.g. a carveout at 0x80000000 vs
> a carveout at 0x60000000) or heap types?
> 
> For heap types, I think the policy can be strict - if it's generally
> useful then it should live in-tree in ion. Otherwise, it would be
> out-of-tree. I'd expect most "custom" heaps to be parameterisable to
> the point of being generally useful.
> 

I'm willing to be reasonably permissive in what lives in tree. A good
example would be something like a heap for the OMAP tiler which had
weird hardware requirements. The associated devices that go with the
heap should be well supported upstream though.

> For actual heap instances, I would expect them to be communicated via
> reserved-memory regions or something similar, and so the maintenance
> burden is pretty low.
> 

Yes. After the next round of review for this series I'm going to
start thinking about properties for chunk and carveout heaps if nobody
proposes something first.

> The existing query ioctl can allow heap IDs to get assigned
> dynamically at runtime, so there's no need to reserve "bit 6" for
> "CUSTOM_ACME_HEAP_1"
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ? For example, until now, in Android
>> we have to give the same
>> access rights to all the process that use ION.
>> It will become problem when we will add secure heaps because we won't
>> be able to distinguish secure
>> processes to standard ones or set specific policy per heaps.
>> Maybe I'm wrong here but I have never see selinux policy checking an
>> ioctl field but if that
>> exist it could be a solution.
>>
> 
> I might be thinking of a different type of "secure", but...
> 
> Should the security of secure heaps be enforced by OS-level
> permissions? I don't know about other architectures, but at least on
> arm/arm64 this is enforced in hardware; it doesn't matter who has
> access to the ion heap, because only secure devices (or the CPU
> running a secure process) is physically able to access the memory
> backing the buffer.
> 
> In fact, in the use-cases I know of, the process asking for the ion
> allocation is not a secure process, and so we wouldn't *want* to
> restrict the secure heap to be allocated from only by secure
> processes.
> 
> -Brian
> 
>>>
>>>>

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Rob Clark]

On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott <labbott@redhat.com> wrote:
>> Hm, we might want to expose all the heaps as individual
>> /dev/ion_$heapname nodes? Should we do this from the start, since
>> we're massively revamping the uapi anyway (imo not needed, current
>> state seems to work too)?
>> -Daniel
>>
>
> I thought about that. One advantage with separate /dev/ion_$heap
> is that we don't have to worry about a limit of 32 possible
> heaps per system (32-bit heap id allocation field). But dealing
> with an ioctl seems easier than names. Userspace might be less
> likely to hardcode random id numbers vs. names as well.


other advantage, I think, is selinux (brought up elsewhere on this
thread).. heaps at known fixed PAs are useful for certain sorts of
attacks so being able to restrict access more easily seems like a good
thing

BR,
-R

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 06:21 AM, Mark Brown wrote:
> On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote:
>> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote:
> 
>>> Another point is how can we put secure rules (like selinux policy) on
>>> heaps since all the allocations
>>> go to the same device (/dev/ion) ? For example, until now, in Android
>>> we have to give the same
>>> access rights to all the process that use ION.
>>> It will become problem when we will add secure heaps because we won't
>>> be able to distinguish secure
>>> processes to standard ones or set specific policy per heaps.
>>> Maybe I'm wrong here but I have never see selinux policy checking an
>>> ioctl field but if that
>>> exist it could be a solution.
> 
>> I might be thinking of a different type of "secure", but...
> 
>> Should the security of secure heaps be enforced by OS-level
>> permissions? I don't know about other architectures, but at least on
>> arm/arm64 this is enforced in hardware; it doesn't matter who has
>> access to the ion heap, because only secure devices (or the CPU
>> running a secure process) is physically able to access the memory
>> backing the buffer.
> 3
>> In fact, in the use-cases I know of, the process asking for the ion
>> allocation is not a secure process, and so we wouldn't *want* to
>> restrict the secure heap to be allocated from only by secure
>> processes.
> 
> I think there's an orthogonal level of OS level security that can be
> applied here - it's reasonable for it to want to say things like "only
> processes that are supposed to be implementing functionality X should be
> able to try to allocate memory set aside for that functionality".  This
> mitigates against escallation attacks and so on, it's not really
> directly related to secure memory as such though.
> 

Ion also makes it pretty trivial to allocate large amounts of kernel
memory and possibly DoS the system. I'd like to have as little
policy in Ion as possible but more important would be a general
security review and people shouting "bad idea ahead".

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/13/2017 02:29 PM, Rob Clark wrote:
> On Mon, Mar 13, 2017 at 5:09 PM, Laura Abbott <labbott@redhat.com> wrote:
>>> Hm, we might want to expose all the heaps as individual
>>> /dev/ion_$heapname nodes? Should we do this from the start, since
>>> we're massively revamping the uapi anyway (imo not needed, current
>>> state seems to work too)?
>>> -Daniel
>>>
>>
>> I thought about that. One advantage with separate /dev/ion_$heap
>> is that we don't have to worry about a limit of 32 possible
>> heaps per system (32-bit heap id allocation field). But dealing
>> with an ioctl seems easier than names. Userspace might be less
>> likely to hardcode random id numbers vs. names as well.
> 
> 
> other advantage, I think, is selinux (brought up elsewhere on this
> thread).. heaps at known fixed PAs are useful for certain sorts of
> attacks so being able to restrict access more easily seems like a good
> thing
> 
> BR,
> -R
> 

Some other kind of filtering (BPF/LSM/???) might work as well
(http://kernsec.org/files/lss2015/vanderstoep.pdf ?)

The fixed PA issue is a larger problem. We're never going to
be able to get away from "this heap must exist at address X"
problems but the location of CMA in general should be
randomized. I haven't actually come up with a good proposal
to this though.

I'd like for Ion to be a framework for memory allocation and
not security exploits. Hopefully this isn't a pipe dream.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-13 22:09 GMT+01:00 Laura Abbott <labbott@redhat.com>:
> On 03/12/2017 12:05 PM, Daniel Vetter wrote:
>> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
>> <benjamin.gaignard@linaro.org> wrote:
>>> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>>>
>>>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>>>> series here addresses a big chunk of that.
>>>>>>>
>>>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>>>> syncpt stuff.
>>>>>>>
>>>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>>>> comfortable with it over time, or at least not managed to come up with
>>>>>>> any better ideas in the meantime.
>>>>>>
>>>>>> See the TODO, it has everything a really big group (look at the patch for
>>>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>>>> merge stuff because merging stuff is fun :-)
>>>>>>
>>>>>> Laurent was even in that group ...
>>>>>> -Daniel
>>>>>
>>>>> For me those patches are going in the right direction.
>>>>>
>>>>> I still have few questions:
>>>>> - since alignment management has been remove from ion-core, should it
>>>>> be also removed from ioctl structure ?
>>>>
>>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>>> so we don't need the compat layer and as part of that I'm also
>>>> dropping the align argument.
>>>>
>>>>> - can you we ride off ion_handle (at least in userland) and only
>>>>> export a dma-buf descriptor ?
>>>>
>>>> Yes, I think this is the right direction given we're breaking
>>>> everything anyway. I was debating trying to keep the two but
>>>> moving to only dma bufs is probably cleaner. The only reason
>>>> I could see for keeping the handles is running out of file
>>>> descriptors for dma-bufs but that seems unlikely.
>>>>>
>>>>> In the future how can we add new heaps ?
>>>>> Some platforms have very specific memory allocation
>>>>> requirements (just have a look in the number of gem custom allocator in drm)
>>>>> Do you plan to add heap type/mask for each ?
>>>>
>>>> Yes, that was my thinking.
>>>
>>> My concern is about the policy to adding heaps, will you accept
>>> "customs" heap per
>>> platforms ? per devices ? or only generic ones ?
>>> If you are too strict, we will have lot of out-of-tree heaps and if
>>> you accept of of them
>>> it will be a nightmare to maintain....
>>
>> I think ion should expose any heap that's also directly accessible to
>> devices using dma_alloc(_coherent). That should leave very few things
>> left, like your SMA heap.
>>
>>> Another point is how can we put secure rules (like selinux policy) on
>>> heaps since all the allocations
>>> go to the same device (/dev/ion) ? For example, until now, in Android
>>> we have to give the same
>>> access rights to all the process that use ION.
>>> It will become problem when we will add secure heaps because we won't
>>> be able to distinguish secure
>>> processes to standard ones or set specific policy per heaps.
>>> Maybe I'm wrong here but I have never see selinux policy checking an
>>> ioctl field but if that
>>> exist it could be a solution.
>>
>> Hm, we might want to expose all the heaps as individual
>> /dev/ion_$heapname nodes? Should we do this from the start, since
>> we're massively revamping the uapi anyway (imo not needed, current
>> state seems to work too)?
>> -Daniel
>>
>
> I thought about that. One advantage with separate /dev/ion_$heap

Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
I think it would be easier for user to look into one directory rather
then in whole /dev to find the heaps

> is that we don't have to worry about a limit of 32 possible
> heaps per system (32-bit heap id allocation field). But dealing
> with an ioctl seems easier than names. Userspace might be less
> likely to hardcode random id numbers vs. names as well.

In the futur I think that heap type will be replaced by a "get caps"
ioctl which will
describe heap capabilities. At least that is my understanding of kernel part
of "unix memory allocator" project

>
> Thanks,
> Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/14/2017 07:47 AM, Benjamin Gaignard wrote:
> 2017-03-13 22:09 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>> On 03/12/2017 12:05 PM, Daniel Vetter wrote:
>>> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
>>> <benjamin.gaignard@linaro.org> wrote:
>>>> 2017-03-09 18:38 GMT+01:00 Laura Abbott <labbott@redhat.com>:
>>>>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>>>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter <daniel@ffwll.ch>:
>>>>>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>>>>>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>>>>>>
>>>>>>>>> No one gave a thing about android in upstream, so Greg KH just dumped it
>>>>>>>>> all into staging/android/. We've discussed ION a bunch of times, recorded
>>>>>>>>> anything we'd like to fix in staging/android/TODO, and Laura's patch
>>>>>>>>> series here addresses a big chunk of that.
>>>>>>>>
>>>>>>>>> This is pretty much the same approach we (gpu folks) used to de-stage the
>>>>>>>>> syncpt stuff.
>>>>>>>>
>>>>>>>> Well, there's also the fact that quite a few people have issues with the
>>>>>>>> design (like Laurent).  It seems like a lot of them have either got more
>>>>>>>> comfortable with it over time, or at least not managed to come up with
>>>>>>>> any better ideas in the meantime.
>>>>>>>
>>>>>>> See the TODO, it has everything a really big group (look at the patch for
>>>>>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't just
>>>>>>> merge stuff because merging stuff is fun :-)
>>>>>>>
>>>>>>> Laurent was even in that group ...
>>>>>>> -Daniel
>>>>>>
>>>>>> For me those patches are going in the right direction.
>>>>>>
>>>>>> I still have few questions:
>>>>>> - since alignment management has been remove from ion-core, should it
>>>>>> be also removed from ioctl structure ?
>>>>>
>>>>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>>>>> so we don't need the compat layer and as part of that I'm also
>>>>> dropping the align argument.
>>>>>
>>>>>> - can you we ride off ion_handle (at least in userland) and only
>>>>>> export a dma-buf descriptor ?
>>>>>
>>>>> Yes, I think this is the right direction given we're breaking
>>>>> everything anyway. I was debating trying to keep the two but
>>>>> moving to only dma bufs is probably cleaner. The only reason
>>>>> I could see for keeping the handles is running out of file
>>>>> descriptors for dma-bufs but that seems unlikely.
>>>>>>
>>>>>> In the future how can we add new heaps ?
>>>>>> Some platforms have very specific memory allocation
>>>>>> requirements (just have a look in the number of gem custom allocator in drm)
>>>>>> Do you plan to add heap type/mask for each ?
>>>>>
>>>>> Yes, that was my thinking.
>>>>
>>>> My concern is about the policy to adding heaps, will you accept
>>>> "customs" heap per
>>>> platforms ? per devices ? or only generic ones ?
>>>> If you are too strict, we will have lot of out-of-tree heaps and if
>>>> you accept of of them
>>>> it will be a nightmare to maintain....
>>>
>>> I think ion should expose any heap that's also directly accessible to
>>> devices using dma_alloc(_coherent). That should leave very few things
>>> left, like your SMA heap.
>>>
>>>> Another point is how can we put secure rules (like selinux policy) on
>>>> heaps since all the allocations
>>>> go to the same device (/dev/ion) ? For example, until now, in Android
>>>> we have to give the same
>>>> access rights to all the process that use ION.
>>>> It will become problem when we will add secure heaps because we won't
>>>> be able to distinguish secure
>>>> processes to standard ones or set specific policy per heaps.
>>>> Maybe I'm wrong here but I have never see selinux policy checking an
>>>> ioctl field but if that
>>>> exist it could be a solution.
>>>
>>> Hm, we might want to expose all the heaps as individual
>>> /dev/ion_$heapname nodes? Should we do this from the start, since
>>> we're massively revamping the uapi anyway (imo not needed, current
>>> state seems to work too)?
>>> -Daniel
>>>
>>
>> I thought about that. One advantage with separate /dev/ion_$heap
> 
> Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
> I think it would be easier for user to look into one directory rather
> then in whole /dev to find the heaps
> 

If we decide to move away from /dev/ion we can consider it.

>> is that we don't have to worry about a limit of 32 possible
>> heaps per system (32-bit heap id allocation field). But dealing
>> with an ioctl seems easier than names. Userspace might be less
>> likely to hardcode random id numbers vs. names as well.
> 
> In the futur I think that heap type will be replaced by a "get caps"
> ioctl which will
> describe heap capabilities. At least that is my understanding of kernel part
> of "unix memory allocator" project
> 

I don't think it will be completely replaced. A heap can have multiple
capabilities so I suspect there will need to be some cap -> allocation
instance translation. Of course all this is wild speculation since
much of the unix memory allocator isn't well defined yet.

Thanks,
Laura

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Nicolas Dufresne]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

Le mardi 14 mars 2017 à 15:47 +0100, Benjamin Gaignard a écrit :
> Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
> I think it would be easier for user to look into one directory rather
> then in whole /dev to find the heaps
> 
> > is that we don't have to worry about a limit of 32 possible
> > heaps per system (32-bit heap id allocation field). But dealing
> > with an ioctl seems easier than names. Userspace might be less
> > likely to hardcode random id numbers vs. names as well.
> 
> In the futur I think that heap type will be replaced by a "get caps"
> ioctl which will
> describe heap capabilities. At least that is my understanding of
> kernel part
> of "unix memory allocator" project

I think what we really need from userspace point of view, is the
ability to find a compatible heap for a set of drivers. And this
without specific knowledge of the drivers.

Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

[Laura Abbott]

On 03/10/2017 12:53 AM, Sumit Semwal wrote:
> Hi Laura,
> 
> Thanks for the patch.
> 
> On 3 March 2017 at 03:14, Laura Abbott <labbott@redhat.com> wrote:
>>
>> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
>> useful to have an explicit name attached to each region. Store the name
>> in each CMA structure.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>>  drivers/base/dma-contiguous.c |  5 +++--
>>  include/linux/cma.h           |  4 +++-
>>  mm/cma.c                      | 11 +++++++++--
>>  mm/cma.h                      |  1 +
>>  mm/cma_debug.c                |  2 +-
>>  5 files changed, 17 insertions(+), 6 deletions(-)
>>
> <snip>
>> +const char *cma_get_name(const struct cma *cma)
>> +{
>> +       return cma->name ? cma->name : "(undefined)";
>> +}
>> +
> Would it make sense to perhaps have the idx stored as the name,
> instead of 'undefined'? That would make sure that the various cma
> names are still unique.
> 

Good suggestion. I'll see about cleaning that up.

>>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>>                                              int align_order)
>>  {
>> @@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
>>   */
>>  int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>>                                  unsigned int order_per_bit,
>> +                                const char *name,
>>                                  struct cma **res_cma)
>>  {
> 
> Best regards,
> Sumit.
>