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
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;
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;
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,
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;
+}
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
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; }
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
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
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;
}
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
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);
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:
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,
return page;DMA_BIDIRECTIONAL);
} 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,
return page;DMA_BIDIRECTIONAL);
} @@ -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>
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:
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
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
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); -
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
- 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
- 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>
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);
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.
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.
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; +}
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; }
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;
}
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
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
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.
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
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
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
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>
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
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);
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
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>
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
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
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
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
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
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
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
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
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
linaro-mm-sig@lists.linaro.org