Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1591485 > unrolled thread
| Started by | Laura Abbott <labbott@redhat.com> |
|---|---|
| First post | 2017-03-02 22:50 +0100 |
| Last post | 2017-03-03 20:20 +0100 |
| Articles | 20 on this page of 66 — 14 participants |
Back to article view | Back to linux.kernel
[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-03 20:00 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-06 14:50 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:00 +0100
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly Laura Abbott <labbott@redhat.com> - 2017-03-06 20:30 +0100
[RFC PATCH 09/12] cma: Introduce cma_for_each_area Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 03/12] staging: android: ion: Duplicate sg_table Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table "Hillf Danton" <hillf.zj@alibaba-inc.com> - 2017-03-03 09:40 +0100
Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
[RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 16:10 +0100
Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable Laura Abbott <labbott@redhat.com> - 2017-03-03 20:50 +0100
[RFC PATCH 05/12] staging: android: ion: Remove page faulting support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
[RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Dan Carpenter <dan.carpenter@oracle.com> - 2017-03-03 12:10 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Eric Engestrom <eric.engestrom@imgtec.com> - 2017-03-03 13:00 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:40 +0100
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
[RFC PATCH 07/12] staging: android: ion: Remove old platform support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 07/12] staging: android: ion: Remove old platform support Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
[RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-02 22:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:00 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 18:00 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-03 19:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Emil Velikov <emil.l.velikov@gmail.com> - 2017-03-06 18:40 +0100
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support Laura Abbott <labbott@redhat.com> - 2017-03-06 20:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-03 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-03 15:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 20:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 11:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-06 16:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-03 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 18:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-06 09:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Mark Brown <broonie@kernel.org> - 2017-03-06 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-06 17:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-09 11:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-09 19:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-10 11:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Robin Murphy <robin.murphy@arm.com> - 2017-03-10 12:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-10 15:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-10 17:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel@ffwll.ch> - 2017-03-10 13:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Rob Clark <robdclark@gmail.com> - 2017-03-10 15:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-03-12 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Daniel Vetter <daniel.vetter@ffwll.ch> - 2017-03-12 20:10 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:20 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Rob Clark <robdclark@gmail.com> - 2017-03-13 22:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 23:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Brian Starkey <brian.starkey@arm.com> - 2017-03-13 12:00 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Mark Brown <broonie@kernel.org> - 2017-03-13 14:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:50 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-13 22:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Michal Hocko <mhocko@kernel.org> - 2017-03-06 14:40 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-03-03 17:30 +0100
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging Laura Abbott <labbott@redhat.com> - 2017-03-03 20:20 +0100
Page 1 of 4 [1] 2 3 4 Next page →
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging |
| Message-ID | <tgGLL-8cb-5@gated-at.bofh.it> |
Hi, There's been some recent discussions[1] about Ion-like frameworks. There's apparently interest in just keeping Ion since it works reasonablly well. This series does what should be the final clean ups for it to possibly be moved out of staging. This includes the following: - Some general clean up and removal of features that never got a lot of use as far as I can tell. - Fixing up the caching. This is the series I proposed back in December[2] but never heard any feedback on. It will certainly break existing applications that rely on the implicit caching. I'd rather make an effort to move to a model that isn't going directly against the establishement though. - Fixing up the platform support. The devicetree approach was never well recieved by DT maintainers. The proposal here is to think of Ion less as specifying requirements and more of a framework for exposing memory to userspace. - CMA allocations now happen without the need of a dummy device structure. This fixes a bunch of the reasons why I attempted to add devicetree support before. I've had problems getting feedback in the past so if I don't hear any major objections I'm going to send out with the RFC dropped to be picked up. The only reason there isn't a patch to come out of staging is to discuss any other changes to the ABI people might want. Once this comes out of staging, I really don't want to mess with the ABI. Feedback appreciated. Thanks, Laura [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2 [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2 Laura Abbott (12): staging: android: ion: Remove dmap_cnt staging: android: ion: Remove alignment from allocation field staging: android: ion: Duplicate sg_table staging: android: ion: Call dma_map_sg for syncing and mapping staging: android: ion: Remove page faulting support staging: android: ion: Remove crufty cache support staging: android: ion: Remove old platform support cma: Store a name in the cma structure cma: Introduce cma_for_each_area staging: android: ion: Use CMA APIs directly staging: android: ion: Make Ion heaps selectable staging; android: ion: Enumerate all available heaps drivers/base/dma-contiguous.c | 5 +- drivers/staging/android/ion/Kconfig | 51 ++-- drivers/staging/android/ion/Makefile | 14 +- drivers/staging/android/ion/hisilicon/Kconfig | 5 - drivers/staging/android/ion/hisilicon/Makefile | 1 - drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 --------- drivers/staging/android/ion/ion-ioctl.c | 6 - drivers/staging/android/ion/ion.c | 282 ++++++--------------- drivers/staging/android/ion/ion.h | 5 +- drivers/staging/android/ion/ion_carveout_heap.c | 16 +- drivers/staging/android/ion/ion_chunk_heap.c | 15 +- drivers/staging/android/ion/ion_cma_heap.c | 102 ++------ drivers/staging/android/ion/ion_dummy_driver.c | 156 ------------ drivers/staging/android/ion/ion_enumerate.c | 89 +++++++ drivers/staging/android/ion/ion_of.c | 184 -------------- drivers/staging/android/ion/ion_of.h | 37 --- drivers/staging/android/ion/ion_page_pool.c | 3 - drivers/staging/android/ion/ion_priv.h | 57 ++++- drivers/staging/android/ion/ion_system_heap.c | 14 +- drivers/staging/android/ion/tegra/Makefile | 1 - drivers/staging/android/ion/tegra/tegra_ion.c | 80 ------ include/linux/cma.h | 6 +- mm/cma.c | 25 +- mm/cma.h | 1 + mm/cma_debug.c | 2 +- 25 files changed, 312 insertions(+), 958 deletions(-) delete mode 100644 drivers/staging/android/ion/hisilicon/Kconfig delete mode 100644 drivers/staging/android/ion/hisilicon/Makefile delete mode 100644 drivers/staging/android/ion/hisilicon/hi6220_ion.c delete mode 100644 drivers/staging/android/ion/ion_dummy_driver.c create mode 100644 drivers/staging/android/ion/ion_enumerate.c delete mode 100644 drivers/staging/android/ion/ion_of.c delete mode 100644 drivers/staging/android/ion/ion_of.h delete mode 100644 drivers/staging/android/ion/tegra/Makefile delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c -- 2.7.4
[toc] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 01/12] staging: android: ion: Remove dmap_cnt |
| Message-ID | <tgGLM-8cb-7@gated-at.bofh.it> |
| In reply to | #1591485 |
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion_priv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index 5b3059c..46d3ff5 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -44,7 +44,6 @@
* @lock: protects the buffers cnt fields
* @kmap_cnt: number of times the buffer is mapped to the kernel
* @vaddr: the kernel mapping if kmap_cnt is not zero
- * @dmap_cnt: number of times the buffer is mapped for dma
* @sg_table: the sg table for the buffer if dmap_cnt is not zero
* @pages: flat array of pages in the buffer -- used by fault
* handler and only valid for buffers that are faulted in
@@ -70,7 +69,6 @@ struct ion_buffer {
struct mutex lock;
int kmap_cnt;
void *vaddr;
- int dmap_cnt;
struct sg_table *sg_table;
struct page **pages;
struct list_head vmas;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <tgGLM-8cb-17@gated-at.bofh.it> |
| In reply to | #1591485 |
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also avoids awkward
caching questions.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion_cma_heap.c | 97 ++++++++----------------------
1 file changed, 26 insertions(+), 71 deletions(-)
diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..6838825 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
#include <linux/slab.h>
#include <linux/errno.h>
#include <linux/err.h>
-#include <linux/dma-mapping.h>
+#include <linux/cma.h>
+#include <linux/scatterlist.h>
#include "ion.h"
#include "ion_priv.h"
struct ion_cma_heap {
struct ion_heap heap;
- struct device *dev;
+ struct cma *cma;
};
#define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
-struct ion_cma_buffer_info {
- void *cpu_addr;
- dma_addr_t handle;
- struct sg_table *table;
-};
-
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
unsigned long flags)
{
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
- struct device *dev = cma_heap->dev;
- struct ion_cma_buffer_info *info;
-
- dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
- if (buffer->flags & ION_FLAG_CACHED)
- return -EINVAL;
+ struct sg_table *table;
+ struct page *pages;
+ int ret;
- info = kzalloc(sizeof(*info), GFP_KERNEL);
- if (!info)
+ pages = cma_alloc(cma_heap->cma, len, 0);
+ if (!pages)
return -ENOMEM;
- info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
- GFP_HIGHUSER | __GFP_ZERO);
-
- if (!info->cpu_addr) {
- dev_err(dev, "Fail to allocate buffer\n");
+ table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+ if (!table)
goto err;
- }
- info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
- if (!info->table)
+ ret = sg_alloc_table(table, 1, GFP_KERNEL);
+ if (ret)
goto free_mem;
- if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
- len))
- goto free_table;
- /* keep this for memory release */
- buffer->priv_virt = info;
- buffer->sg_table = info->table;
- dev_dbg(dev, "Allocate buffer %p\n", buffer);
+ sg_set_page(table->sgl, pages, len, 0);
+
+ buffer->priv_virt = pages;
+ buffer->sg_table = table;
return 0;
-free_table:
- kfree(info->table);
free_mem:
- dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+ kfree(table);
err:
- kfree(info);
+ cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
}
static void ion_cma_free(struct ion_buffer *buffer)
{
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
- struct device *dev = cma_heap->dev;
- struct ion_cma_buffer_info *info = buffer->priv_virt;
+ struct page *pages = buffer->priv_virt;
- dev_dbg(dev, "Release buffer %p\n", buffer);
/* release memory */
- dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
+ cma_release(cma_heap->cma, pages, buffer->size);
/* release sg table */
- sg_free_table(info->table);
- kfree(info->table);
- kfree(info);
-}
-
-static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
- struct vm_area_struct *vma)
-{
- struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
- struct device *dev = cma_heap->dev;
- struct ion_cma_buffer_info *info = buffer->priv_virt;
-
- return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
- buffer->size);
-}
-
-static void *ion_cma_map_kernel(struct ion_heap *heap,
- struct ion_buffer *buffer)
-{
- struct ion_cma_buffer_info *info = buffer->priv_virt;
- /* kernel memory mapping has been done at allocation time */
- return info->cpu_addr;
-}
-
-static void ion_cma_unmap_kernel(struct ion_heap *heap,
- struct ion_buffer *buffer)
-{
+ sg_free_table(buffer->sg_table);
+ kfree(buffer->sg_table);
}
static struct ion_heap_ops ion_cma_ops = {
.allocate = ion_cma_allocate,
.free = ion_cma_free,
- .map_user = ion_cma_mmap,
- .map_kernel = ion_cma_map_kernel,
- .unmap_kernel = ion_cma_unmap_kernel,
+ .map_user = ion_heap_map_user,
+ .map_kernel = ion_heap_map_kernel,
+ .unmap_kernel = ion_heap_unmap_kernel,
};
struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
@@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
* get device from private heaps data, later it will be
* used to make the link with reserved CMA memory
*/
- cma_heap->dev = data->priv;
+ cma_heap->cma = data->priv;
cma_heap->heap.type = ION_HEAP_TYPE_DMA;
return &cma_heap->heap;
}
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
|---|---|
| Date | 2017-03-03 17:50 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <tgYyZ-3Rj-13@gated-at.bofh.it> |
| In reply to | #1591487 |
Hi Laura,
Thank you for the patch.
On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also avoids awkward
> caching questions.
If the DMA mapping API isn't suitable for today's requirements anymore, I
believe that's what needs to be fixed, instead of working around the problem
by introducing another use-case-specific API.
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> drivers/staging/android/ion/ion_cma_heap.c | 97 +++++++--------------------
> 1 file changed, 26 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..6838825 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
> #include <linux/slab.h>
> #include <linux/errno.h>
> #include <linux/err.h>
> -#include <linux/dma-mapping.h>
> +#include <linux/cma.h>
> +#include <linux/scatterlist.h>
>
> #include "ion.h"
> #include "ion_priv.h"
>
> struct ion_cma_heap {
> struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
> };
>
> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
>
> /* ION CMA heap operations functions */
> static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer
> *buffer, @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap
> *heap, struct ion_buffer *buffer, unsigned long flags)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
>
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0);
> + if (!pages)
> return -ENOMEM;
>
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
> goto err;
> - }
>
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
> goto free_mem;
>
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
> return 0;
>
> -free_table:
> - kfree(info->table);
> free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
> err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
> return -ENOMEM;
> }
>
> static void ion_cma_free(struct ion_buffer *buffer)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> + struct page *pages = buffer->priv_virt;
>
> - dev_dbg(dev, "Release buffer %p\n", buffer);
> /* release memory */
> - dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle);
> + cma_release(cma_heap->cma, pages, buffer->size);
> /* release sg table */
> - sg_free_table(info->table);
> - kfree(info->table);
> - kfree(info);
> -}
> -
> -static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer,
> - struct vm_area_struct *vma)
> -{
> - struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> -
> - return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle,
> - buffer->size);
> -}
> -
> -static void *ion_cma_map_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> - struct ion_cma_buffer_info *info = buffer->priv_virt;
> - /* kernel memory mapping has been done at allocation time */
> - return info->cpu_addr;
> -}
> -
> -static void ion_cma_unmap_kernel(struct ion_heap *heap,
> - struct ion_buffer *buffer)
> -{
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
> }
>
> static struct ion_heap_ops ion_cma_ops = {
> .allocate = ion_cma_allocate,
> .free = ion_cma_free,
> - .map_user = ion_cma_mmap,
> - .map_kernel = ion_cma_map_kernel,
> - .unmap_kernel = ion_cma_unmap_kernel,
> + .map_user = ion_heap_map_user,
> + .map_kernel = ion_heap_map_kernel,
> + .unmap_kernel = ion_heap_unmap_kernel,
> };
>
> struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
> @@ -147,7 +102,7 @@ struct ion_heap *ion_cma_heap_create(struct
> ion_platform_heap *data) * get device from private heaps data, later it
> will be
> * used to make the link with reserved CMA memory
> */
> - cma_heap->dev = data->priv;
> + cma_heap->cma = data->priv;
> cma_heap->heap.type = ION_HEAP_TYPE_DMA;
> return &cma_heap->heap;
> }
--
Regards,
Laurent Pinchart
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-03 20:00 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <th0AN-5fC-7@gated-at.bofh.it> |
| In reply to | #1592129 |
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
[toc] | [prev] | [next] | [standalone]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2017-03-06 11:50 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <thYng-6U9-25@gated-at.bofh.it> |
| In reply to | #1592220 |
On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > > Hi Laura, > > > > Thank you for the patch. > > > > On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >> When CMA was first introduced, its primary use was for DMA allocation > >> and the only way to get CMA memory was to call dma_alloc_coherent. This > >> put Ion in an awkward position since there was no device structure > >> readily available and setting one up messed up the coherency model. > >> These days, CMA can be allocated directly from the APIs. Switch to using > >> this model to avoid needing a dummy device. This also avoids awkward > >> caching questions. > > > > If the DMA mapping API isn't suitable for today's requirements anymore, I > > believe that's what needs to be fixed, instead of working around the problem > > by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > DMA already because it's used in other places. The trying to go through > DMA was just another layer of abstraction, especially since there isn't > a device available for allocation. Also, we've had separation of allocation and dma-mapping since forever, that's how it works almost everywhere. Not exactly sure why/how arm-soc ecosystem ended up focused so much on dma_alloc_coherent. I think separating allocation from dma mapping/coherency is perfectly fine, and the way to go. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[toc] | [prev] | [next] | [standalone]
| From | Laurent Pinchart <laurent.pinchart@ideasonboard.com> |
|---|---|
| Date | 2017-03-06 14:50 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <ti1br-uP-5@gated-at.bofh.it> |
| In reply to | #1593182 |
Hi Daniel, On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > >>> When CMA was first introduced, its primary use was for DMA allocation > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > >>> put Ion in an awkward position since there was no device structure > >>> readily available and setting one up messed up the coherency model. > >>> These days, CMA can be allocated directly from the APIs. Switch to > >>> using this model to avoid needing a dummy device. This also avoids > >>> awkward caching questions. > >> > >> If the DMA mapping API isn't suitable for today's requirements anymore, > >> I believe that's what needs to be fixed, instead of working around the > >> problem by introducing another use-case-specific API. > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > DMA already because it's used in other places. The trying to go through > > DMA was just another layer of abstraction, especially since there isn't > > a device available for allocation. > > Also, we've had separation of allocation and dma-mapping since forever, > that's how it works almost everywhere. Not exactly sure why/how arm-soc > ecosystem ended up focused so much on dma_alloc_coherent. I believe because that was the easy way to specify memory constraints. The API receives a device pointer and will allocate memory suitable for DMA for that device. The fact that it maps it to the device is a side-effect in my opinion. > I think separating allocation from dma mapping/coherency is perfectly > fine, and the way to go. Especially given that in many cases we'll want to share buffers between multiple devices, so we'll need to map them multiple times. My point still stands though, if we want to move towards a model where allocation and mapping are decoupled, we need an allocation function that takes constraints (possibly implemented with two layers, a constraint resolution layer on top of a pool/heap/type/foo-based allocator), and a mapping API. IOMMU handling being integrated in the DMA mapping API we're currently stuck with it, which might call for brushing up that API. -- Regards, Laurent Pinchart
[toc] | [prev] | [next] | [standalone]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2017-03-06 17:00 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <ti3dg-1Ug-13@gated-at.bofh.it> |
| In reply to | #1593322 |
On Mon, Mar 06, 2017 at 03:43:53PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Monday 06 Mar 2017 11:32:04 Daniel Vetter wrote: > > On Fri, Mar 03, 2017 at 10:50:20AM -0800, Laura Abbott wrote: > > > On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > > >> On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: > > >>> When CMA was first introduced, its primary use was for DMA allocation > > >>> and the only way to get CMA memory was to call dma_alloc_coherent. This > > >>> put Ion in an awkward position since there was no device structure > > >>> readily available and setting one up messed up the coherency model. > > >>> These days, CMA can be allocated directly from the APIs. Switch to > > >>> using this model to avoid needing a dummy device. This also avoids > > >>> awkward caching questions. > > >> > > >> If the DMA mapping API isn't suitable for today's requirements anymore, > > >> I believe that's what needs to be fixed, instead of working around the > > >> problem by introducing another use-case-specific API. > > > > > > I don't think this is a usecase specific API. CMA has been decoupled from > > > DMA already because it's used in other places. The trying to go through > > > DMA was just another layer of abstraction, especially since there isn't > > > a device available for allocation. > > > > Also, we've had separation of allocation and dma-mapping since forever, > > that's how it works almost everywhere. Not exactly sure why/how arm-soc > > ecosystem ended up focused so much on dma_alloc_coherent. > > I believe because that was the easy way to specify memory constraints. The API > receives a device pointer and will allocate memory suitable for DMA for that > device. The fact that it maps it to the device is a side-effect in my opinion. > > > I think separating allocation from dma mapping/coherency is perfectly > > fine, and the way to go. > > Especially given that in many cases we'll want to share buffers between > multiple devices, so we'll need to map them multiple times. > > My point still stands though, if we want to move towards a model where > allocation and mapping are decoupled, we need an allocation function that > takes constraints (possibly implemented with two layers, a constraint > resolution layer on top of a pool/heap/type/foo-based allocator), and a > mapping API. IOMMU handling being integrated in the DMA mapping API we're > currently stuck with it, which might call for brushing up that API. Hm, maybe I wasn't clear, but that's exactly what I assume will happen: The constraint resolver is the unix device memory allocation thing, which happens entirely in userspace. There's a lot more than just "where to allocate" to negotiate, e.g. pixel format, stride/size limits/requirements, tiling formats. A lot of it the kernel doesn't even know. Allocation then needs to happen through the kernel ofc, but that doesn't mean we need to have all the constraint resolving in the kernel. As long as the kernel exposes the device /dev node -> ion heap stuff, userspace can figure this out. Or an alternative way would be to have a cascade of ion heaps to keep things a notch more opaque. Either way, no actaul constraint resolving in the kernel itself, and except for a bunch more stuff in sysfs maybe, also no other uapi changes. Once we have a place to allocate stuff which isn't the device driver at least, aka ION. And then once allocated you use the dma apis to instantiate the iommus mappings. Anyway, at least from my understanding I think there's 0 risk with merging ION wrt the constraint resolving side (at least as discussed around XDC last year), and for setups that need cma, it might finally enable to get things moving forward. Or do I miss something big here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-06 20:30 +0100 |
| Subject | Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly |
| Message-ID | <ti6ut-4kC-11@gated-at.bofh.it> |
| In reply to | #1593488 |
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
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 09/12] cma: Introduce cma_for_each_area |
| Message-ID | <tgGLM-8cb-19@gated-at.bofh.it> |
| In reply to | #1591485 |
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
include/linux/cma.h | 2 ++
mm/cma.c | 14 ++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 49f98ea..b521e3c 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -33,4 +33,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int align);
extern bool cma_release(struct cma *cma, const struct page *pages, unsigned int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 4a93d2b..a430df0 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -464,3 +464,17 @@ bool cma_release(struct cma *cma, const struct page *pages, unsigned int count)
return true;
}
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+ int i;
+
+ for (i = 0; i < cma_area_count; i++) {
+ int ret = it(&cma_areas[i], data);
+
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table |
| Message-ID | <tgGLM-8cb-11@gated-at.bofh.it> |
| In reply to | #1591485 |
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 94a498e..ce4adac 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -799,6 +799,32 @@ static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
struct device *dev,
enum dma_data_direction direction);
+static struct sg_table *dup_sg_table(struct sg_table *table)
+{
+ struct sg_table *new_table;
+ int ret, i;
+ struct scatterlist *sg, *new_sg;
+
+ new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
+ if (!new_table)
+ return ERR_PTR(-ENOMEM);
+
+ ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
+ if (ret) {
+ kfree(table);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ new_sg = new_table->sgl;
+ for_each_sg(table->sgl, sg, table->nents, i) {
+ memcpy(new_sg, sg, sizeof(*sg));
+ sg->dma_address = 0;
+ new_sg = sg_next(new_sg);
+ }
+
+ return new_table;
+}
+
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
@@ -806,13 +832,15 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
ion_buffer_sync_for_device(buffer, attachment->dev, direction);
- return buffer->sg_table;
+ return dup_sg_table(buffer->sg_table);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ sg_free_table(table);
+ kfree(table);
}
void ion_pages_sync_for_device(struct device *dev, struct page *page,
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | "Hillf Danton" <hillf.zj@alibaba-inc.com> |
|---|---|
| Date | 2017-03-03 09:40 +0100 |
| Subject | Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table |
| Message-ID | <tgQUP-6Ye-25@gated-at.bofh.it> |
| In reply to | #1591489 |
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;
> +}
> +
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-03 19:50 +0100 |
| Subject | Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table |
| Message-ID | <th0r8-5c2-15@gated-at.bofh.it> |
| In reply to | #1591748 |
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
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable |
| Message-ID | <tgGLM-8cb-13@gated-at.bofh.it> |
| In reply to | #1591485 |
Currently, all heaps are compiled in all the time. In switching to
a better platform model, let's allow these to be compiled out for good
measure.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/Kconfig | 32 ++++++++++++++++++++
drivers/staging/android/ion/Makefile | 8 +++--
drivers/staging/android/ion/ion_priv.h | 53 ++++++++++++++++++++++++++++++++--
3 files changed, 87 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
index 0c91b2b..2e97990 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -17,3 +17,35 @@ config ION_TEST
Choose this option to create a device that can be used to test the
kernel and device side ION functions.
+config ION_SYSTEM_HEAP
+ bool "Ion system heap"
+ depends on ION
+ help
+ Choose this option to enable the Ion system heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+ bool "Ion carveout heap support"
+ depends on ION
+ help
+ Choose this option to enable carveout heaps with Ion. Carveout heaps
+ are backed by memory reserved from the system. Allocation times are
+ typically faster at the cost of memory not being used. Unless you
+ know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+ bool "Ion chunk heap support"
+ depends on ION
+ help
+ Choose this option to enable chunk heaps with Ion. This heap is
+ similar in function the carveout heap but memory is broken down
+ into smaller chunk sizes, typically corresponding to a TLB size.
+ Unless you know your system has these regions, you should say N here.
+
+config ION_CMA_HEAP
+ bool "Ion CMA heap support"
+ depends on ION && CMA
+ help
+ Choose this option to enable CMA heaps with Ion. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
index 9457090..eef022b 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,8 @@
-obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
- ion_page_pool.o ion_system_heap.o \
- ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
obj-$(CONFIG_ION_TEST) += ion_test.o
ifdef CONFIG_COMPAT
obj-$(CONFIG_ION) += compat_ion.o
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index b09bc7c..6eafe0d 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
* heaps as appropriate.
*/
+
struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
void ion_heap_destroy(struct ion_heap *heap);
+
+#ifdef CONFIG_ION_SYSTEM_HEAP
struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
void ion_system_heap_destroy(struct ion_heap *heap);
-
struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *heap);
void ion_system_contig_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap * ion_system_heap_create(
+ struct ion_platform_heap *unused)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
+
+static inline struct ion_heap *ion_system_contig_heap_create(
+ struct ion_platform_heap *heap)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CARVEOUT_HEAP
struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
void ion_carveout_heap_destroy(struct ion_heap *heap);
-
+#else
+static inline struct ion_heap *ion_carveout_heap_create(
+ struct ion_platform_heap *heap_data)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void ion_carveout_heap_destroy(struct ion_heap *heap) { }
+#endif
+
+#ifdef CONFIG_ION_CHUNK_HEAP
struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
void ion_chunk_heap_destroy(struct ion_heap *heap);
+#else
+static inline struct ion_heap *ion_chunk_heap_create(
+ struct ion_platform_heap *heap_data)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void ion_chunk_heap_destroy(struct ion_heap *heap) { }
+
+#endif
+
+#ifdef CONFIG_ION_CMA_HEAP
struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
void ion_cma_heap_destroy(struct ion_heap *heap);
+#else
+static inline struct ion_heap *ion_cma_heap_create(
+ struct ion_platform_heap *data)
+{
+ return ERR_PTR(-ENODEV);
+}
+static inline void ion_cma_heap_destroy(struct ion_heap *heap) { }
+#endif
/**
* functions for creating and destroying a heap pool -- allows you
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Daniel Vetter <daniel@ffwll.ch> |
|---|---|
| Date | 2017-03-03 16:10 +0100 |
| Subject | Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable |
| Message-ID | <tgX0e-2X9-19@gated-at.bofh.it> |
| In reply to | #1591490 |
On Thu, Mar 02, 2017 at 01:44:43PM -0800, Laura Abbott wrote:
>
> Currently, all heaps are compiled in all the time. In switching to
> a better platform model, let's allow these to be compiled out for good
> measure.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
I'm not the biggest fan of making everything Kconfig-selectable. And the
#ifdef stuff doesn't look all that pretty. If we'd also use this
opportunity to split each heap into their own file I think this patch here
would be a lot more useful.
Anyway, no real opinion from me on this, just an idea.
-Daniel
> ---
> drivers/staging/android/ion/Kconfig | 32 ++++++++++++++++++++
> drivers/staging/android/ion/Makefile | 8 +++--
> drivers/staging/android/ion/ion_priv.h | 53 ++++++++++++++++++++++++++++++++--
> 3 files changed, 87 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig b/drivers/staging/android/ion/Kconfig
> index 0c91b2b..2e97990 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -17,3 +17,35 @@ config ION_TEST
> Choose this option to create a device that can be used to test the
> kernel and device side ION functions.
>
> +config ION_SYSTEM_HEAP
> + bool "Ion system heap"
> + depends on ION
> + help
> + Choose this option to enable the Ion system heap. The system heap
> + is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config ION_CARVEOUT_HEAP
> + bool "Ion carveout heap support"
> + depends on ION
> + help
> + Choose this option to enable carveout heaps with Ion. Carveout heaps
> + are backed by memory reserved from the system. Allocation times are
> + typically faster at the cost of memory not being used. Unless you
> + know your system has these regions, you should say N here.
> +
> +config ION_CHUNK_HEAP
> + bool "Ion chunk heap support"
> + depends on ION
> + help
> + Choose this option to enable chunk heaps with Ion. This heap is
> + similar in function the carveout heap but memory is broken down
> + into smaller chunk sizes, typically corresponding to a TLB size.
> + Unless you know your system has these regions, you should say N here.
> +
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> + Choose this option to enable CMA heaps with Ion. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile b/drivers/staging/android/ion/Makefile
> index 9457090..eef022b 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,8 @@
> -obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> - ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> +obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
> +obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
> +obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
> +obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> obj-$(CONFIG_ION_TEST) += ion_test.o
> ifdef CONFIG_COMPAT
> obj-$(CONFIG_ION) += compat_ion.o
> diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
> index b09bc7c..6eafe0d 100644
> --- a/drivers/staging/android/ion/ion_priv.h
> +++ b/drivers/staging/android/ion/ion_priv.h
> @@ -369,21 +369,68 @@ size_t ion_heap_freelist_size(struct ion_heap *heap);
> * heaps as appropriate.
> */
>
> +
> struct ion_heap *ion_heap_create(struct ion_platform_heap *heap_data);
> void ion_heap_destroy(struct ion_heap *heap);
> +
> +#ifdef CONFIG_ION_SYSTEM_HEAP
> struct ion_heap *ion_system_heap_create(struct ion_platform_heap *unused);
> void ion_system_heap_destroy(struct ion_heap *heap);
> -
> struct ion_heap *ion_system_contig_heap_create(struct ion_platform_heap *heap);
> void ion_system_contig_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap * ion_system_heap_create(
> + struct ion_platform_heap *unused)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_system_heap_destroy(struct ion_heap *heap) { }
> +
> +static inline struct ion_heap *ion_system_contig_heap_create(
> + struct ion_platform_heap *heap)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +
> +static inline void ion_system_contig_heap_destroy(struct ion_heap *heap) { }
> +#endif
> +
> +#ifdef CONFIG_ION_CARVEOUT_HEAP
> struct ion_heap *ion_carveout_heap_create(struct ion_platform_heap *heap_data);
> void ion_carveout_heap_destroy(struct ion_heap *heap);
> -
> +#else
> +static inline struct ion_heap *ion_carveout_heap_create(
> + struct ion_platform_heap *heap_data)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_carveout_heap_destroy(struct ion_heap *heap) { }
> +#endif
> +
> +#ifdef CONFIG_ION_CHUNK_HEAP
> struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data);
> void ion_chunk_heap_destroy(struct ion_heap *heap);
> +#else
> +static inline struct ion_heap *ion_chunk_heap_create(
> + struct ion_platform_heap *heap_data)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_chunk_heap_destroy(struct ion_heap *heap) { }
> +
> +#endif
> +
> +#ifdef CONFIG_ION_CMA_HEAP
> struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data);
> void ion_cma_heap_destroy(struct ion_heap *heap);
> +#else
> +static inline struct ion_heap *ion_cma_heap_create(
> + struct ion_platform_heap *data)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +static inline void ion_cma_heap_destroy(struct ion_heap *heap) { }
> +#endif
>
> /**
> * functions for creating and destroying a heap pool -- allows you
> --
> 2.7.4
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-03 20:50 +0100 |
| Subject | Re: [RFC PATCH 11/12] staging: android: ion: Make Ion heaps selectable |
| Message-ID | <th1nc-5Qy-9@gated-at.bofh.it> |
| In reply to | #1592032 |
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
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 05/12] staging: android: ion: Remove page faulting support |
| Message-ID | <tgGLM-8cb-15@gated-at.bofh.it> |
| In reply to | #1591485 |
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 117 --------------------------------------
1 file changed, 117 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index a931b30..8eef1d7 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -41,37 +41,11 @@
#include "ion_priv.h"
#include "compat_ion.h"
-bool ion_buffer_fault_user_mappings(struct ion_buffer *buffer)
-{
- return (buffer->flags & ION_FLAG_CACHED) &&
- !(buffer->flags & ION_FLAG_CACHED_NEEDS_SYNC);
-}
-
bool ion_buffer_cached(struct ion_buffer *buffer)
{
return !!(buffer->flags & ION_FLAG_CACHED);
}
-static inline struct page *ion_buffer_page(struct page *page)
-{
- return (struct page *)((unsigned long)page & ~(1UL));
-}
-
-static inline bool ion_buffer_page_is_dirty(struct page *page)
-{
- return !!((unsigned long)page & 1UL);
-}
-
-static inline void ion_buffer_page_dirty(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) | 1UL);
-}
-
-static inline void ion_buffer_page_clean(struct page **page)
-{
- *page = (struct page *)((unsigned long)(*page) & ~(1UL));
-}
-
/* this function should only be called while dev->lock is held */
static void ion_buffer_add(struct ion_device *dev,
struct ion_buffer *buffer)
@@ -139,25 +113,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
buffer->dev = dev;
buffer->size = len;
- if (ion_buffer_fault_user_mappings(buffer)) {
- int num_pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
- struct scatterlist *sg;
- int i, j, k = 0;
-
- buffer->pages = vmalloc(sizeof(struct page *) * num_pages);
- if (!buffer->pages) {
- ret = -ENOMEM;
- goto err1;
- }
-
- for_each_sg(table->sgl, sg, table->nents, i) {
- struct page *page = sg_page(sg);
-
- for (j = 0; j < sg->length / PAGE_SIZE; j++)
- buffer->pages[k++] = page++;
- }
- }
-
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(&buffer->vmas);
@@ -876,69 +831,6 @@ void ion_pages_sync_for_device(struct device *dev, struct page *page,
dma_sync_sg_for_device(dev, &sg, 1, dir);
}
-struct ion_vma_list {
- struct list_head list;
- struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
-{
- struct ion_buffer *buffer = vma->vm_private_data;
- unsigned long pfn;
- int ret;
-
- mutex_lock(&buffer->lock);
- ion_buffer_page_dirty(buffer->pages + vmf->pgoff);
- BUG_ON(!buffer->pages || !buffer->pages[vmf->pgoff]);
-
- pfn = page_to_pfn(ion_buffer_page(buffer->pages[vmf->pgoff]));
- ret = vm_insert_pfn(vma, vmf->address, pfn);
- mutex_unlock(&buffer->lock);
- if (ret)
- return VM_FAULT_ERROR;
-
- return VM_FAULT_NOPAGE;
-}
-
-static void ion_vm_open(struct vm_area_struct *vma)
-{
- struct ion_buffer *buffer = vma->vm_private_data;
- struct ion_vma_list *vma_list;
-
- vma_list = kmalloc(sizeof(*vma_list), GFP_KERNEL);
- if (!vma_list)
- return;
- vma_list->vma = vma;
- mutex_lock(&buffer->lock);
- list_add(&vma_list->list, &buffer->vmas);
- mutex_unlock(&buffer->lock);
- pr_debug("%s: adding %p\n", __func__, vma);
-}
-
-static void ion_vm_close(struct vm_area_struct *vma)
-{
- struct ion_buffer *buffer = vma->vm_private_data;
- struct ion_vma_list *vma_list, *tmp;
-
- pr_debug("%s\n", __func__);
- mutex_lock(&buffer->lock);
- list_for_each_entry_safe(vma_list, tmp, &buffer->vmas, list) {
- if (vma_list->vma != vma)
- continue;
- list_del(&vma_list->list);
- kfree(vma_list);
- pr_debug("%s: deleting %p\n", __func__, vma);
- break;
- }
- mutex_unlock(&buffer->lock);
-}
-
-static const struct vm_operations_struct ion_vma_ops = {
- .open = ion_vm_open,
- .close = ion_vm_close,
- .fault = ion_vm_fault,
-};
-
static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
{
struct ion_buffer *buffer = dmabuf->priv;
@@ -950,15 +842,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
return -EINVAL;
}
- if (ion_buffer_fault_user_mappings(buffer)) {
- vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND |
- VM_DONTDUMP;
- vma->vm_private_data = buffer;
- vma->vm_ops = &ion_vma_ops;
- ion_vm_open(vma);
- return 0;
- }
-
if (!(buffer->flags & ION_FLAG_CACHED))
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 02/12] staging: android: ion: Remove alignment from allocation field |
| Message-ID | <tgGLM-8cb-23@gated-at.bofh.it> |
| In reply to | #1591485 |
The align field was supposed to be used to specify the alignment of
the allocation. Nobody actually does anything with it except to check
if the alignment specified is out of bounds. Since this has no effect
on the actual allocation, just remove it.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/ion/ion.c | 14 ++++++--------
drivers/staging/android/ion/ion.h | 5 +----
drivers/staging/android/ion/ion_carveout_heap.c | 10 +++-------
drivers/staging/android/ion/ion_chunk_heap.c | 9 +++------
drivers/staging/android/ion/ion_cma_heap.c | 5 +----
drivers/staging/android/ion/ion_priv.h | 2 +-
drivers/staging/android/ion/ion_system_heap.c | 9 +--------
8 files changed, 16 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c
index 9ff815a..5b2e93f 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -95,7 +95,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
struct ion_handle *handle;
handle = ion_alloc(client, data.allocation.len,
- data.allocation.align,
data.allocation.heap_id_mask,
data.allocation.flags);
if (IS_ERR(handle))
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 9696007..94a498e 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -102,7 +102,6 @@ static void ion_buffer_add(struct ion_device *dev,
static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
struct ion_device *dev,
unsigned long len,
- unsigned long align,
unsigned long flags)
{
struct ion_buffer *buffer;
@@ -118,15 +117,14 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
buffer->flags = flags;
kref_init(&buffer->ref);
- ret = heap->ops->allocate(heap, buffer, len, align, flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret) {
if (!(heap->flags & ION_HEAP_FLAG_DEFER_FREE))
goto err2;
ion_heap_freelist_drain(heap, 0);
- ret = heap->ops->allocate(heap, buffer, len, align,
- flags);
+ ret = heap->ops->allocate(heap, buffer, len, flags);
if (ret)
goto err2;
}
@@ -400,7 +398,7 @@ static int ion_handle_add(struct ion_client *client, struct ion_handle *handle)
}
struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
- size_t align, unsigned int heap_id_mask,
+ unsigned int heap_id_mask,
unsigned int flags)
{
struct ion_handle *handle;
@@ -409,8 +407,8 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
struct ion_heap *heap;
int ret;
- pr_debug("%s: len %zu align %zu heap_id_mask %u flags %x\n", __func__,
- len, align, heap_id_mask, flags);
+ pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
+ len, heap_id_mask, flags);
/*
* traverse the list of heaps available in this system in priority
* order. If the heap type is supported by the client, and matches the
@@ -427,7 +425,7 @@ struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
- buffer = ion_buffer_create(heap, dev, len, align, flags);
+ buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
index 93dafb4..3b4bff5 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -45,7 +45,6 @@ struct ion_buffer;
* @name: used for debug purposes
* @base: base address of heap in physical memory if applicable
* @size: size of the heap in bytes if applicable
- * @align: required alignment in physical memory if applicable
* @priv: private info passed from the board file
*
* Provided by the board file.
@@ -93,8 +92,6 @@ void ion_client_destroy(struct ion_client *client);
* ion_alloc - allocate ion memory
* @client: the client
* @len: size of the allocation
- * @align: requested allocation alignment, lots of hardware blocks
- * have alignment requirements of some kind
* @heap_id_mask: mask of heaps to allocate from, if multiple bits are set
* heaps will be tried in order from highest to lowest
* id
@@ -106,7 +103,7 @@ void ion_client_destroy(struct ion_client *client);
* an opaque handle to it.
*/
struct ion_handle *ion_alloc(struct ion_client *client, size_t len,
- size_t align, unsigned int heap_id_mask,
+ unsigned int heap_id_mask,
unsigned int flags);
/**
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c b/drivers/staging/android/ion/ion_carveout_heap.c
index a8ea973..9bf8e98 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -34,8 +34,7 @@ struct ion_carveout_heap {
};
static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
- unsigned long size,
- unsigned long align)
+ unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
container_of(heap, struct ion_carveout_heap, heap);
@@ -60,16 +59,13 @@ static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
static int ion_carveout_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct sg_table *table;
ion_phys_addr_t paddr;
int ret;
- if (align > PAGE_SIZE)
- return -EINVAL;
-
table = kmalloc(sizeof(*table), GFP_KERNEL);
if (!table)
return -ENOMEM;
@@ -77,7 +73,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
if (ret)
goto err_free;
- paddr = ion_carveout_allocate(heap, size, align);
+ paddr = ion_carveout_allocate(heap, size);
if (paddr == ION_CARVEOUT_ALLOCATE_FAIL) {
ret = -ENOMEM;
goto err_free_table;
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c b/drivers/staging/android/ion/ion_chunk_heap.c
index 70495dc..8c41889 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -35,7 +35,7 @@ struct ion_chunk_heap {
static int ion_chunk_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct ion_chunk_heap *chunk_heap =
@@ -46,9 +46,6 @@ static int ion_chunk_heap_allocate(struct ion_heap *heap,
unsigned long num_chunks;
unsigned long allocated_size;
- if (align > chunk_heap->chunk_size)
- return -EINVAL;
-
allocated_size = ALIGN(size, chunk_heap->chunk_size);
num_chunks = allocated_size / chunk_heap->chunk_size;
@@ -160,8 +157,8 @@ struct ion_heap *ion_chunk_heap_create(struct ion_platform_heap *heap_data)
chunk_heap->heap.ops = &chunk_heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
- pr_debug("%s: base %lu size %zu align %ld\n", __func__,
- chunk_heap->base, heap_data->size, heap_data->align);
+ pr_debug("%s: base %lu size %zu \n", __func__,
+ chunk_heap->base, heap_data->size);
return &chunk_heap->heap;
diff --git a/drivers/staging/android/ion/ion_cma_heap.c b/drivers/staging/android/ion/ion_cma_heap.c
index 6c40685..d562fd7 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -40,7 +40,7 @@ struct ion_cma_buffer_info {
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
- unsigned long len, unsigned long align,
+ unsigned long len,
unsigned long flags)
{
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
@@ -52,9 +52,6 @@ static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
if (buffer->flags & ION_FLAG_CACHED)
return -EINVAL;
- if (align > PAGE_SIZE)
- return -EINVAL;
-
info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
diff --git a/drivers/staging/android/ion/ion_priv.h b/drivers/staging/android/ion/ion_priv.h
index 46d3ff5..b09bc7c 100644
--- a/drivers/staging/android/ion/ion_priv.h
+++ b/drivers/staging/android/ion/ion_priv.h
@@ -172,7 +172,7 @@ struct ion_handle {
struct ion_heap_ops {
int (*allocate)(struct ion_heap *heap,
struct ion_buffer *buffer, unsigned long len,
- unsigned long align, unsigned long flags);
+ unsigned long flags);
void (*free)(struct ion_buffer *buffer);
void * (*map_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
void (*unmap_kernel)(struct ion_heap *heap, struct ion_buffer *buffer);
diff --git a/drivers/staging/android/ion/ion_system_heap.c b/drivers/staging/android/ion/ion_system_heap.c
index 3ebbb75..6cb2fe7 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -129,7 +129,7 @@ static struct page *alloc_largest_available(struct ion_system_heap *heap,
static int ion_system_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
- unsigned long size, unsigned long align,
+ unsigned long size,
unsigned long flags)
{
struct ion_system_heap *sys_heap = container_of(heap,
@@ -143,9 +143,6 @@ static int ion_system_heap_allocate(struct ion_heap *heap,
unsigned long size_remaining = PAGE_ALIGN(size);
unsigned int max_order = orders[0];
- if (align > PAGE_SIZE)
- return -EINVAL;
-
if (size / PAGE_SIZE > totalram_pages / 2)
return -ENOMEM;
@@ -372,7 +369,6 @@ void ion_system_heap_destroy(struct ion_heap *heap)
static int ion_system_contig_heap_allocate(struct ion_heap *heap,
struct ion_buffer *buffer,
unsigned long len,
- unsigned long align,
unsigned long flags)
{
int order = get_order(len);
@@ -381,9 +377,6 @@ static int ion_system_contig_heap_allocate(struct ion_heap *heap,
unsigned long i;
int ret;
- if (align > (PAGE_SIZE << order))
- return -EINVAL;
-
page = alloc_pages(low_order_gfp_flags, order);
if (!page)
return -ENOMEM;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Laura Abbott <labbott@redhat.com> |
|---|---|
| Date | 2017-03-02 22:50 +0100 |
| Subject | [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping |
| Message-ID | <tgGLM-8cb-21@gated-at.bofh.it> |
| In reply to | #1591485 |
Technically, calling dma_buf_map_attachment should return a buffer
properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
ensure this happens. As a side effect, this lets Ion buffers take
advantage of the dma_buf sync ioctls.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
drivers/staging/android/ion/ion.c | 101 +++++++++++++++++++-------------------
1 file changed, 50 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index ce4adac..a931b30 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
}
EXPORT_SYMBOL(ion_client_destroy);
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
- struct device *dev,
- enum dma_data_direction direction);
-
static struct sg_table *dup_sg_table(struct sg_table *table)
{
struct sg_table *new_table;
@@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table *table)
return new_table;
}
+static void free_duped_table(struct sg_table *table)
+{
+ sg_free_table(table);
+ kfree(table);
+}
+
static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
{
struct dma_buf *dmabuf = attachment->dmabuf;
struct ion_buffer *buffer = dmabuf->priv;
+ struct sg_table *table;
+ int ret;
+
+ /*
+ * TODO: Need to sync wrt CPU or device completely owning?
+ */
+
+ table = dup_sg_table(buffer->sg_table);
- ion_buffer_sync_for_device(buffer, attachment->dev, direction);
- return dup_sg_table(buffer->sg_table);
+ if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
+ direction)){
+ ret = -ENOMEM;
+ goto err;
+ }
+
+err:
+ free_duped_table(table);
+ return ERR_PTR(ret);
}
static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
- sg_free_table(table);
- kfree(table);
+ dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+ free_duped_table(table);
}
void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -864,38 +881,6 @@ struct ion_vma_list {
struct vm_area_struct *vma;
};
-static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
- struct device *dev,
- enum dma_data_direction dir)
-{
- struct ion_vma_list *vma_list;
- int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
- int i;
-
- pr_debug("%s: syncing for device %s\n", __func__,
- dev ? dev_name(dev) : "null");
-
- if (!ion_buffer_fault_user_mappings(buffer))
- return;
-
- mutex_lock(&buffer->lock);
- for (i = 0; i < pages; i++) {
- struct page *page = buffer->pages[i];
-
- if (ion_buffer_page_is_dirty(page))
- ion_pages_sync_for_device(dev, ion_buffer_page(page),
- PAGE_SIZE, dir);
-
- ion_buffer_page_clean(buffer->pages + i);
- }
- list_for_each_entry(vma_list, &buffer->vmas, list) {
- struct vm_area_struct *vma = vma_list->vma;
-
- zap_page_range(vma, vma->vm_start, vma->vm_end - vma->vm_start);
- }
- mutex_unlock(&buffer->lock);
-}
-
static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct ion_buffer *buffer = vma->vm_private_data;
@@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
struct ion_buffer *buffer = dmabuf->priv;
void *vaddr;
- if (!buffer->heap->ops->map_kernel) {
- pr_err("%s: map kernel is not implemented by this heap.\n",
- __func__);
- return -ENODEV;
+ /*
+ * TODO: Move this elsewhere because we don't always need a vaddr
+ */
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ vaddr = ion_buffer_kmap_get(buffer);
+ mutex_unlock(&buffer->lock);
}
- mutex_lock(&buffer->lock);
- vaddr = ion_buffer_kmap_get(buffer);
- mutex_unlock(&buffer->lock);
- return PTR_ERR_OR_ZERO(vaddr);
+ /*
+ * Close enough right now? Flag to skip sync?
+ */
+ if (!dma_map_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+ DMA_BIDIRECTIONAL))
+ return -ENOMEM;
+
+ return 0;
}
static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
@@ -1031,9 +1024,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
{
struct ion_buffer *buffer = dmabuf->priv;
- mutex_lock(&buffer->lock);
- ion_buffer_kmap_put(buffer);
- mutex_unlock(&buffer->lock);
+ if (buffer->heap->ops->map_kernel) {
+ mutex_lock(&buffer->lock);
+ ion_buffer_kmap_put(buffer);
+ mutex_unlock(&buffer->lock);
+ }
+
+ dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+ buffer->sg_table->nents,
+ DMA_BIDIRECTIONAL);
return 0;
}
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Dan Carpenter <dan.carpenter@oracle.com> |
|---|---|
| Date | 2017-03-03 12:10 +0100 |
| Subject | Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping |
| Message-ID | <tgTfY-kD-9@gated-at.bofh.it> |
| In reply to | #1591495 |
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
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | linux.kernel
csiph-web