Re: [PATCH] staging: android: ion: Fix dma direction for dma_sync_sg_for_cpu/device

2017-12-18 Thread Laura Abbott

On 12/15/2017 12:59 PM, Sushmita Susheelendra wrote:

Use the direction argument passed into begin_cpu_access
and end_cpu_access when calling the dma_sync_sg_for_cpu/device.
The actual cache primitive called depends on the direction
passed in.



Acked-by: Laura Abbott <labb...@redhat.com>


Signed-off-by: Sushmita Susheelendra <ssush...@codeaurora.org>
---
  drivers/staging/android/ion/ion.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index a7d9b0e..f480885 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -346,7 +346,7 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf 
*dmabuf,
mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
-   DMA_BIDIRECTIONAL);
+   direction);
}
mutex_unlock(>lock);
  
@@ -368,7 +368,7 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,

mutex_lock(>lock);
list_for_each_entry(a, >attachments, list) {
dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents,
-  DMA_BIDIRECTIONAL);
+  direction);
}
mutex_unlock(>lock);
  





Re: [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

2017-04-19 Thread Laura Abbott

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
Reviewed-by: Sinclair Yeh <s...@vmware.com>
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)



For Ion,

Acked-by: Laura Abbott <labb...@redhat.com>

I did some major Ion refactoring but I don't think this
will conflict.

Thanks,
Laura


[PATCHv4 01/12] cma: Store a name in the cma structure

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

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

diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 4d6c64b..b739ff8 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -100,7 +100,8 @@ void __init kvm_cma_reserve(void)
 (unsigned long)selected_size / SZ_1M);
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
cma_declare_contiguous(0, selected_size, 0, align_size,
-   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, _cma);
+   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
+   _cma);
}
 }
 
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b55804c..ea9726e 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;
 
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
 
-   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
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 03f32d0..d41d1f8 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,
  gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..43c1b2c 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;
@@ -198,6 +204,13 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 * subsystems (like slab allocator) are available.
 */
cma = _areas[cma_area_count];
+   if (name) {
+   cma->name = name;
+   } else {
+   cma->name = kasprintf(GFP_KERNEL, "cma%d\n", cma_area_count);
+   if (!cma->name)
+   return -ENOMEM;
+   }
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
@@ -229,7 +242,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

[PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress

2017-04-18 Thread Laura Abbott
Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Makefile |   3 -
 drivers/staging/android/ion/compat_ion.c | 152 ---
 drivers/staging/android/ion/compat_ion.h |  29 --
 drivers/staging/android/ion/ion-ioctl.c  |   1 -
 drivers/staging/android/ion/ion.c|   5 +-
 drivers/staging/android/uapi/ion.h   |  19 ++--
 6 files changed, 11 insertions(+), 198 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ 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
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 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 
-#include 
-#include 
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs 
*/
-struct compat_ion_allocation_data {
-   compat_size_t len;
-   compat_size_t align;
-   compat_uint_t heap_id_mask;
-   compat_uint_t flags;
-   compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
-   compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC   _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_get_ion_handle_data(
-   struct compat_ion_handle_data __user *data32,
-   struct ion_handle_data __user *data)
-{
-   compat_int_t i;
-   int err;
-
-   err = get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_put_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
-   long ret;
-
-   if (!filp->f_op->unlocked_ioctl)
-   return -ENOTTY;
-
-   switch (cmd) {
-   case COMPAT_ION_IOC_ALLOC:
-   {
-   struct compat_ion_allocation_data __user *data32;
-   

[PATCHv4 02/12] cma: Introduce cma_for_each_area

2017-04-18 Thread Laura Abbott
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.

Signed-off-by: Laura Abbott <labb...@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 d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align,
  gfp_t gfp_mask);
 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 43c1b2c..978b4a1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -504,3 +504,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(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4



[PATCHv4 03/12] staging: android: ion: Use CMA APIs directly

2017-04-18 Thread Laura Abbott
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v4: Put some #ifdef around CMA heap functions. This is ugly but gets removed
a few patches later.
---
 drivers/staging/android/ion/Kconfig|  7 +++
 drivers/staging/android/ion/Makefile   |  3 +-
 drivers/staging/android/ion/ion_cma_heap.c | 97 --
 drivers/staging/android/ion/ion_heap.c |  4 ++
 4 files changed, 39 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
  If you're not using Android its probably safe to
  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 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
 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
+   ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #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, GFP_KERNEL);
+   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->c

[PATCHv4 04/12] staging: android: ion: Stop butchering the DMA address

2017-04-18 Thread Laura Abbott
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 {
struct ion_buffer *buffer;
struct sg_table *table;
-   struct scatterlist *sg;
-   int i, ret;
+   int ret;
 
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
INIT_LIST_HEAD(>vmas);
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
-   /*
-* 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
-*/
-   for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
-   sg_dma_address(sg) = sg_phys(sg);
-   sg_dma_len(sg) = sg->length;
-   }
mutex_lock(>buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(>buffer_lock);
-- 
2.7.4



[PATCHv4 06/12] staging: android: ion: Get rid of ion_phys_addr_t

2017-04-18 Thread Laura Abbott
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.h   | 12 ++--
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  6 +++---
 drivers/staging/android/ion/ion_heap.c  |  4 ++--
 4 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
 struct ion_client;
 struct ion_buffer;
 
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t.  For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
-   ion_phys_addr_t base;
+   phys_addr_t base;
size_t size;
-   ion_phys_addr_t align;
+   phys_addr_t align;
void *priv;
 };
 
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
 struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
 };
 
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
 unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap 
*heap,
return offset;
 }
 
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
  unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
  unsigned long flags)
 {
struct sg_table *table;
-   ion_phys_addr_t paddr;
+   phys_addr_t paddr;
int ret;
 
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
-   ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+   phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
 
ion_heap_buffer_zero(buffer);
 
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
 struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _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 \n", __func__,
-chunk_heap->base, heap_data->size);
+   pr_debug("%s: base %pa size %zu \n", __func__,
+_heap->base, heap_data->size);
 
return _heap->heap;
 
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index 66f8fc5..c974623 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -345,9 +345,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap 
*heap_data)
}
 
if (IS_ERR_OR_NULL(heap)) {
-   pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+   pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
   __func__, heap_data->name, heap_data->type,
-  h

[PATCHv4 07/12] staging: android: ion: Collapse internal header files

2017-04-18 Thread Laura Abbott
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v4: minor cleanup suggested by Emil Velikov
---
 drivers/staging/android/ion/ion-ioctl.c |   1 -
 drivers/staging/android/ion/ion.c   |   1 -
 drivers/staging/android/ion/ion.h   | 479 
 drivers/staging/android/ion/ion_carveout_heap.c |   1 -
 drivers/staging/android/ion/ion_chunk_heap.c|   1 -
 drivers/staging/android/ion/ion_cma_heap.c  |   1 -
 drivers/staging/android/ion/ion_heap.c  |   1 -
 drivers/staging/android/ion/ion_page_pool.c |   3 +-
 drivers/staging/android/ion/ion_priv.h  | 453 --
 drivers/staging/android/ion/ion_system_heap.c   |   1 -
 10 files changed, 402 insertions(+), 540 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion_priv.h

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e8a6ffe..fd49403 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -14,24 +14,26 @@
  *
  */
 
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_H
+#define _ION_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 #include "../uapi/ion.h"
 
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
- * @id:unique identifier for heap.  When allocating higher 
numbers
+ * @id:unique identifier for heap.  When allocating higher 
numb ers
  * will be allocated from first.  At allocation these are passed
  * as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
  * @name:  used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
 };
 
 /**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref:   reference count
+ * @node:  node in the ion_device buffers tree
+ * @dev:   back pointer to the ion_device
+ * @heap:  back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size:  size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @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
+ * @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
+ * @vmas:  list of vma's mapping this buffer
+ * @handle_count:  count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid:   pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+   struct kref ref;
+   union {
+   struct rb_node node;
+   struct list_head list;
+   };
+   struct ion_device *dev;
+   struct ion_heap *heap;
+   unsigned long flags;
+   unsigned long private_flags;
+   size_t size;
+   void *priv_virt;
+   struct mutex lock;
+   int kmap_cnt;
+   void *vaddr;
+   struct sg_table *sg_table;
+   struct page **pages;
+   struct list_head vmas;
+   struct list_head attachments;
+   /* used to track orphaned buffers */
+ 

[PATCHv4 09/12] staging: android: ion: Drop ion_map_kernel interface

2017-04-18 Thread Laura Abbott
Nobody uses this interface externally. Drop it.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
 }
 
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
-   struct ion_buffer *buffer = handle->buffer;
-   void *vaddr;
-
-   if (handle->kmap_cnt) {
-   handle->kmap_cnt++;
-   return buffer->vaddr;
-   }
-   vaddr = ion_buffer_kmap_get(buffer);
-   if (IS_ERR(vaddr))
-   return vaddr;
-   handle->kmap_cnt++;
-   return vaddr;
-}
-
 static void ion_buffer_kmap_put(struct ion_buffer *buffer)
 {
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
 }
 
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-   void *vaddr;
-
-   mutex_lock(>lock);
-   if (!ion_handle_validate(client, handle)) {
-   pr_err("%s: invalid handle passed to map_kernel.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-EINVAL);
-   }
-
-   buffer = handle->buffer;
-
-   if (!handle->buffer->heap->ops->map_kernel) {
-   pr_err("%s: map_kernel is not implemented by this heap.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-ENODEV);
-   }
-
-   mutex_lock(>lock);
-   vaddr = ion_handle_kmap_get(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-   return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-
-   mutex_lock(>lock);
-   buffer = handle->buffer;
-   mutex_lock(>lock);
-   ion_handle_kmap_put(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
 static struct mutex debugfs_mutex;
 static struct rb_root *ion_root_client;
 static int is_client_alive(struct ion_client *client)
-- 
2.7.4



[PATCHv4 12/12] staging/android: Update Ion TODO list

2017-04-18 Thread Laura Abbott
Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/TODO | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 8f3ac37..5f14247 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -7,23 +7,10 @@ TODO:
 
 
 ion/
- - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal
-   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
-   first.
- - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
-   vendor trees. Should be replaced with an ioctl on the dma-buf to expose the
-   begin/end_cpu_access hooks to userspace.
- - Clarify the tricks ion plays with explicitly managing coherency behind the
-   dma api's back (this is absolutely needed for high-perf gpu drivers): Add an
-   explicit coherency management mode to flush_for_device to be used by drivers
-   which want to manage caches themselves and which indicates whether cpu 
caches
-   need flushing.
- - With those removed there's probably no use for ION_IOC_IMPORT anymore either
-   since ion would just be the central allocator for shared buffers.
- - Add dt-binding to expose cma regions as ion heaps, with the rule that any
-   such cma regions must already be used by some device for dma. I.e. ion only
-   exposes existing cma regions and doesn't reserve unecessarily memory when
-   booting a system which doesn't use ion.
+ - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
+   involve putting appropriate bindings in a memory node for Ion to find.
+ - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
+ - Better test framework (integration with VGEM was suggested)
 
 Please send patches to Greg Kroah-Hartman <g...@kroah.com> and Cc:
 Arve Hjønnevåg <a...@android.com> and Riley Andrews <riandr...@android.com>
-- 
2.7.4



[PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client

2017-04-18 Thread Laura Abbott
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c |  53 +--
 drivers/staging/android/ion/ion.c   | 701 ++--
 drivers/staging/android/ion/ion.h   |  77 +---
 drivers/staging/android/uapi/ion.h  |  25 +-
 4 files changed, 51 insertions(+), 805 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
 #include "ion.h"
 
 union ion_ioctl_arg {
-   struct ion_fd_data fd;
struct ion_allocation_data allocation;
-   struct ion_handle_data handle;
struct ion_heap_query query;
 };
 
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_FREE:
-   return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
-   struct ion_client *client = filp->private_data;
-   struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
-   struct ion_handle *handle;
+   int fd;
 
-   handle = ion_alloc(client, data.allocation.len,
+   fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
+   if (fd < 0)
+   return fd;
 
-   data.allocation.handle = handle->id;
+   data.allocation.fd = fd;
 
-   cleanup_handle = handle;
-   break;
-   }
-   case ION_IOC_FREE:
-   {
-   struct ion_handle *handle;
-
-   mutex_lock(>lock);
-   handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   return PTR_ERR(handle);
-   }
-   ion_free_nolock(client, handle);
-   ion_handle_put_nolock(handle);
-   mutex_unlock(>lock);
-   break;
-   }
-   case ION_IOC_SHARE:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
-   if (data.fd.fd < 0)
-   ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
-   ret = ion_query_heaps(client, );
+   ret = ion_query_heaps();
break;
default:
return -ENOTTY;
}
 
if (dir & _IOC_READ) {
-   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
-   if (cleanup_handle)
-   ion_free(client, cleanup_handle);
+   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
return -EFAULT;
-   }
}
return ret;
 }
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 5a82bea..9eeb06f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
-   kref_init(>ref);
 
ret = heap->ops-&g

[PATCHv4 08/12] staging: android: ion: Rework heap registration/enumeration

2017-04-18 Thread Laura Abbott
The current model of Ion heap registration  is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig | 25 +
 drivers/staging/android/ion/Makefile|  7 +--
 drivers/staging/android/ion/ion.c   | 28 +-
 drivers/staging/android/ion/ion.h   | 40 +-
 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  | 24 +++--
 drivers/staging/android/ion/ion_heap.c  | 71 -
 drivers/staging/android/ion/ion_system_heap.c   | 38 -
 9 files changed, 85 insertions(+), 167 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+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
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-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
+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
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
 
 #include "ion.h"
 
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
+   struct ion_device *dev = internal_dev;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 
heap->dev = dev;
down_write(>lock);
+   heap->id = heap_id++;
/*
 * use negative heap->id to reverse the priority -- when traversing
 * the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 }
 EXPORT_SYMBOL(ion_device_add_heap);
 
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
 {
 

[PATCHv4 11/12] staging: android: ion: Set query return value

2017-04-18 Thread Laura Abbott
This never got set in the ioctl. Properly set a return value of 0 on
success.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query)
}
 
query->cnt = cnt;
+   ret = 0;
 out:
up_read(>lock);
return ret;
-- 
2.7.4



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

2017-04-18 Thread Laura Abbott
Hi,

This is v4 of the series to cleanup to Ion. Greg took some of the patches
that weren't CMA related already. There was a minor bisectability problem
with the CMA APIs so this is a new version to address that. I also
addressed some minor comments on the patch to collapse header files.

Thanks,
Laura

Laura Abbott (12):
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Stop butchering the DMA address
  staging: android: ion: Break the ABI in the name of forward progress
  staging: android: ion: Get rid of ion_phys_addr_t
  staging: android: ion: Collapse internal header files
  staging: android: ion: Rework heap registration/enumeration
  staging: android: ion: Drop ion_map_kernel interface
  staging: android: ion: Remove ion_handle and ion_client
  staging: android: ion: Set query return value
  staging/android: Update Ion TODO list

 arch/powerpc/kvm/book3s_hv_builtin.c|   3 +-
 drivers/base/dma-contiguous.c   |   5 +-
 drivers/staging/android/TODO|  21 +-
 drivers/staging/android/ion/Kconfig |  32 +
 drivers/staging/android/ion/Makefile|  11 +-
 drivers/staging/android/ion/compat_ion.c| 152 -
 drivers/staging/android/ion/compat_ion.h|  29 -
 drivers/staging/android/ion/ion-ioctl.c |  55 +-
 drivers/staging/android/ion/ion.c   | 812 ++--
 drivers/staging/android/ion/ion.h   | 386 ---
 drivers/staging/android/ion/ion_carveout_heap.c |  21 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  16 +-
 drivers/staging/android/ion/ion_cma_heap.c  | 120 ++--
 drivers/staging/android/ion/ion_heap.c  |  68 --
 drivers/staging/android/ion/ion_page_pool.c |   3 +-
 drivers/staging/android/ion/ion_priv.h  | 453 -
 drivers/staging/android/ion/ion_system_heap.c   |  39 +-
 drivers/staging/android/uapi/ion.h  |  36 +-
 include/linux/cma.h |   6 +-
 mm/cma.c|  31 +-
 mm/cma.h|   1 +
 mm/cma_debug.c  |   2 +-
 22 files changed, 524 insertions(+), 1778 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h
 delete mode 100644 drivers/staging/android/ion/ion_priv.h

-- 
2.7.4



Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

2017-04-11 Thread Laura Abbott
On 04/10/2017 11:47 PM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Monday 03 Apr 2017 11:57:55 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 mitigates some of
>> the caching problems (e.g. dma_alloc_coherent only returning uncached
>> memory).
> 
> Do we have a guarantee that the DMA mapping API, which we have to use for 
> cache handling, will always support memory we allocate directly from CMA 
> behind its back ?
> 

CMA pages are no different than other pages allocated via the buddy
allocator. There should be no issue passing that memory to the
streaming API.

Thanks,
Laura

>> Signed-off-by: Laura Abbott <labb...@redhat.com>
>> ---
>>  drivers/staging/android/ion/Kconfig|  7 +++
>>  drivers/staging/android/ion/Makefile   |  3 +-
>>  drivers/staging/android/ion/ion_cma_heap.c | 97 +++
>>  3 files changed, 35 insertions(+), 72 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/Kconfig
>> b/drivers/staging/android/ion/Kconfig index 206c4de..15108c4 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -10,3 +10,10 @@ menuconfig ION
>>If you're not using Android its probably safe to
>>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 26672a0..66d0c4a 100644
>> --- a/drivers/staging/android/ion/Makefile
>> +++ b/drivers/staging/android/ion/Makefile
>> @@ -1,6 +1,7 @@
>>  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
>> +ion_carveout_heap.o ion_chunk_heap.o
>> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>>  ifdef CONFIG_COMPAT
>>  obj-$(CONFIG_ION) += compat_ion.o
>>  endif
>> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
>> b/drivers/staging/android/ion/ion_cma_heap.c index d562fd7..f3e0f59 100644
>> --- a/drivers/staging/android/ion/ion_cma_heap.c
>> +++ b/drivers/staging/android/ion/ion_cma_heap.c
>> @@ -19,24 +19,19 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>> +#include 
>>
>>  #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, GFP_KERNEL);
>> +if (!pages)
>>  return -ENOMEM;
>>
>> -info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
>> -GFP_HIGHUSER | __GFP_ZERO);
>> -
>> -i

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

2017-04-10 Thread Laura Abbott
On 04/10/2017 09:25 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 10, 2017 at 09:20:27AM -0700, Laura Abbott wrote:
>> On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
>>> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>>>> Hi,
>>>>
>>>> This is v3 of the series to do some serious Ion cleanup in preparation for
>>>> moving out of staging. I didn't hear much on v2 so I'm going to assume
>>>> people are okay with the series as is. I know there were still some open
>>>> questions about moving away from /dev/ion but in the interest of small
>>>> steps I'd like to go ahead and merge this series assuming there are no more
>>>> major objections. More work can happen on top of this.
>>>
>>> I've applied patches 3-11 as those were independant of the CMA changes.
>>> I'd like to take the rest, including the CMA changes, but I need an ack
>>> from someone dealing with the -mm tree before I can do that.
>>>
>>> Or, if they just keep ignoring it, I guess I can take them :)
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
>> any, I'll resend the rest of the series after the 4.12 merge window.
> 
> Why so long?  This series has been sent a bunch, if no one responds in a
> week, I'll be glad to take them all in my tree :)
> 
> thanks,
> 
> greg k-h
> 

Ideally I'd like some confirmation that at least someone other than
myself thinks it's a good idea but I know mm review bandwidth has
been a topic of discussion so maybe silence is the best I can get.
If you pick it up and nobody objects, I guess I won't object either :)

Thanks,
Laura


Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

2017-04-10 Thread Laura Abbott
On 04/08/2017 03:38 AM, Greg Kroah-Hartman wrote:
> On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote:
>> Hi,
>>
>> This is v3 of the series to do some serious Ion cleanup in preparation for
>> moving out of staging. I didn't hear much on v2 so I'm going to assume
>> people are okay with the series as is. I know there were still some open
>> questions about moving away from /dev/ion but in the interest of small
>> steps I'd like to go ahead and merge this series assuming there are no more
>> major objections. More work can happen on top of this.
> 
> I've applied patches 3-11 as those were independant of the CMA changes.
> I'd like to take the rest, including the CMA changes, but I need an ack
> from someone dealing with the -mm tree before I can do that.
> 
> Or, if they just keep ignoring it, I guess I can take them :)
> 
> thanks,
> 
> greg k-h
> 

Thanks. I'll send out some nag e-mails asking for Acks. If I don't get
any, I'll resend the rest of the series after the 4.12 merge window.

Thanks,
Laura


Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files

2017-04-10 Thread Laura Abbott
On 04/08/2017 11:12 AM, Emil Velikov wrote:
> Hi Laura,
> 
> Couple of trivial nitpicks below.
> 
> On 3 April 2017 at 19:57, Laura Abbott <labb...@redhat.com> wrote:
> 
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -1,5 +1,5 @@
>>  /*
>> - * drivers/staging/android/ion/ion.h
>> + * drivers/staging/android/ion/ion_priv.h
> Does not match the actual filename.
> 
>>   *
>>   * Copyright (C) 2011 Google, Inc.
>>   *
>> @@ -14,24 +14,26 @@
>>   *
>>   */
>>
>> -#ifndef _LINUX_ION_H
>> -#define _LINUX_ION_H
>> +#ifndef _ION_PRIV_H
>> +#define _ION_PRIV_H
>>
> Ditto.
> 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>>  #include 
>> +#include 
>>
>>  #include "../uapi/ion.h"
>>
> You don't want to use "../" in includes. Perhaps address with another
> patch, if you haven't already ?
> 

There isn't a better option until this driver moves out of staging.
Once it moves out it can be fixed up.

Thanks,
Laura

> Regards,
> Emil
> 



[PATCHv3 01/22] cma: Store a name in the cma structure

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
v3: Added default name suggestion per Sumit. Fixup powerpc call site.
---
 arch/powerpc/kvm/book3s_hv_builtin.c |  3 ++-
 drivers/base/dma-contiguous.c|  5 +++--
 include/linux/cma.h  |  4 +++-
 mm/cma.c | 17 +++--
 mm/cma.h |  1 +
 mm/cma_debug.c   |  2 +-
 6 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c 
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 4d6c64b..b739ff8 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -100,7 +100,8 @@ void __init kvm_cma_reserve(void)
 (unsigned long)selected_size / SZ_1M);
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
cma_declare_contiguous(0, selected_size, 0, align_size,
-   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, _cma);
+   KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
+   _cma);
}
 }
 
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b55804c..ea9726e 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;
 
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
 
-   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
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 03f32d0..d41d1f8 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,
  gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..43c1b2c 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;
@@ -198,6 +204,13 @@ int __init cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 * subsystems (like slab allocator) are available.
 */
cma = _areas[cma_area_count];
+   if (name) {
+   cma->name = name;
+   } else {
+   cma->name = kasprintf(GFP_KERNEL, "cma%d\n", cma_area_count);
+   if (!cma->name)
+   return -ENOMEM;
+   }
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
@@ -229,7 +242,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,
 

[PATCHv3 02/22] cma: Introduce cma_for_each_area

2017-04-03 Thread Laura Abbott
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.

Signed-off-by: Laura Abbott <labb...@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 d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align,
  gfp_t gfp_mask);
 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 43c1b2c..978b4a1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -504,3 +504,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(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4



[PATCHv3 07/22] staging: android: ion: Remove page faulting support

2017-04-03 Thread Laura Abbott
The new method of syncing with dma_map means that the page faulting sync
implementation is no longer applicable. Remove it.

Signed-off-by: Laura Abbott <labb...@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 6aac935..226ea1f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -42,37 +42,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)
@@ -140,25 +114,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(>vmas);
@@ -924,69 +879,6 @@ void ion_pages_sync_for_device(struct device *dev, struct 
page *page,
dma_sync_sg_for_device(dev, , 1, dir);
 }
 
-struct ion_vma_list {
-   struct list_head list;
-   struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vmf->vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>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(vmf->vma, vmf->address, pfn);
-   mutex_unlock(>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(>lock);
-   list_add(_list->list, >vmas);
-   mutex_unlock(>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(>lock);
-   list_for_each_entry_safe(vma_list, tmp, >vmas, list) {
-   if (vma_list->vma != vma)
-   continue;
-   list_del(_list->list);
-   kfree(vma_list);
-   pr_debug("%s: deleting %p\n", __func__, vma);
-   break;
-   }
-   mutex_unlock(>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;
@@ -998,15 +890,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
- 

[PATCHv3 03/22] staging: android: ion: Remove dmap_cnt

2017-04-03 Thread Laura Abbott
The reference counting of dma_map calls was removed. Remove the
associated counter field as well.

Signed-off-by: Laura Abbott <labb...@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



[PATCHv3 06/22] staging: android: ion: Call dma_map_sg for syncing and mapping

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c  | 151 ++---
 drivers/staging/android/ion/ion_priv.h |   1 +
 2 files changed, 103 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7dcb8a9..6aac935 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -162,6 +162,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
+   INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
/*
 * this will set up dma addresses for the sglist -- it is not
@@ -796,10 +797,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;
@@ -826,22 +823,89 @@ 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);
+}
+
+struct ion_dma_buf_attachment {
+   struct device *dev;
+   struct sg_table *table;
+   struct list_head list;
+};
+
+static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a;
+   struct sg_table *table;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   table = dup_sg_table(buffer->sg_table);
+   if (IS_ERR(table)) {
+   kfree(a);
+   return -ENOMEM;
+   }
+
+   a->table = table;
+   a->dev = dev;
+   INIT_LIST_HEAD(>list);
+
+   attachment->priv = a;
+
+   mutex_lock(>lock);
+   list_add(>list, >attachments);
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a = attachment->priv;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   free_duped_table(a->table);
+   mutex_lock(>lock);
+   list_del(>list);
+   mutex_unlock(>lock);
+
+   kfree(a);
+}
+
+
 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 ion_dma_buf_attachment *a = attachment->priv;
+   struct sg_table *table;
+   int ret;
+
+   table = a->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;
+   }
+   return table;
+
+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);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -865,38 +929,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(>lock);
-   for (i = 0; i < pages; i++) {
-   struct page *page = buffer->pages[i];
-
-   if (ion_buffer_page_is_dirty(page))
-

[PATCHv3 04/22] staging: android: ion: Remove alignment from allocation field

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

Signed-off-by: Laura Abbott <labb...@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 f45115f..c2adfe1 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -103,7 +103,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;
@@ -119,15 +118,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>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;
}
@@ -401,7 +399,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;
@@ -410,8 +408,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
@@ -428,7 +426,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 - allocat

[PATCHv3 10/22] staging: android: ion: Remove import interface

2017-04-03 Thread Laura Abbott
With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  | 11 -
 drivers/staging/android/ion/ion.c| 76 
 drivers/staging/android/uapi/ion.h   |  9 
 4 files changed, 97 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 5b192ea..ae1ffc3 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -145,7 +145,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
case ION_IOC_SHARE:
case ION_IOC_MAP:
-   case ION_IOC_IMPORT:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 2b475bf..7b54eea 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -131,17 +131,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
ret = data.fd.fd;
break;
}
-   case ION_IOC_IMPORT:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_import_dma_buf_fd(client, data.fd.fd);
-   if (IS_ERR(handle))
-   ret = PTR_ERR(handle);
-   else
-   data.handle.handle = handle->id;
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 125c537..3d979ef5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,24 +274,6 @@ int ion_handle_put(struct ion_handle *handle)
return ret;
 }
 
-static struct ion_handle *ion_handle_lookup(struct ion_client *client,
-   struct ion_buffer *buffer)
-{
-   struct rb_node *n = client->handles.rb_node;
-
-   while (n) {
-   struct ion_handle *entry = rb_entry(n, struct ion_handle, node);
-
-   if (buffer < entry->buffer)
-   n = n->rb_left;
-   else if (buffer > entry->buffer)
-   n = n->rb_right;
-   else
-   return entry;
-   }
-   return ERR_PTR(-EINVAL);
-}
-
 struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client *client,
   int id)
 {
@@ -1023,64 +1005,6 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
struct ion_handle *handle)
 }
 EXPORT_SYMBOL(ion_share_dma_buf_fd);
 
-struct ion_handle *ion_import_dma_buf(struct ion_client *client,
- struct dma_buf *dmabuf)
-{
-   struct ion_buffer *buffer;
-   struct ion_handle *handle;
-   int ret;
-
-   /* if this memory came from ion */
-
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not import dmabuf from another exporter\n",
-  __func__);
-   return ERR_PTR(-EINVAL);
-   }
-   buffer = dmabuf->priv;
-
-   mutex_lock(>lock);
-   /* if a handle exists for this buffer just take a reference to it */
-   handle = ion_handle_lookup(client, buffer);
-   if (!IS_ERR(handle)) {
-   ion_handle_get(handle);
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   handle = ion_handle_create(client, buffer);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   ret = ion_handle_add(client, handle);
-   mutex_unlock(>lock);
-   if (ret) {
-   ion_handle_put(handle);
-   handle = ERR_PTR(ret);
-   }
-
-end:
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf);
-
-struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_handle *handle;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return ERR_CAST(dmabuf);
-
-   handle = ion_import_dma_buf(client, dmabuf);
-   dma_buf_put(dmabuf);
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf_fd);
-
 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/uapi/ion.h 
b/drivers/staging/android/uapi/ion

[PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

2017-04-03 Thread Laura Abbott
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig|  7 +++
 drivers/staging/android/ion/Makefile   |  3 +-
 drivers/staging/android/ion/ion_cma_heap.c | 97 --
 3 files changed, 35 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
  If you're not using Android its probably safe to
  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 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
 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
+   ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #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, GFP_KERNEL);
+   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_h

[PATCHv3 09/22] staging: android: ion: Remove custom ioctl interface

2017-04-03 Thread Laura Abbott
Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c   | 40 --
 drivers/staging/android/ion/ion-ioctl.c| 11 ---
 drivers/staging/android/ion/ion.c  |  6 +---
 drivers/staging/android/ion/ion_dummy_driver.c |  2 +-
 drivers/staging/android/ion/ion_priv.h |  8 +-
 drivers/staging/android/uapi/ion.h | 21 --
 6 files changed, 3 insertions(+), 85 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index b892d3a..5b192ea 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -30,11 +30,6 @@ struct compat_ion_allocation_data {
compat_int_t handle;
 };
 
-struct compat_ion_custom_data {
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-};
-
 struct compat_ion_handle_data {
compat_int_t handle;
 };
@@ -43,8 +38,6 @@ struct compat_ion_handle_data {
  struct compat_ion_allocation_data)
 #define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
  struct compat_ion_handle_data)
-#define COMPAT_ION_IOC_CUSTOM  _IOWR(ION_IOC_MAGIC, 6, \
- struct compat_ion_custom_data)
 
 static int compat_get_ion_allocation_data(
struct compat_ion_allocation_data __user *data32,
@@ -105,22 +98,6 @@ static int compat_put_ion_allocation_data(
return err;
 }
 
-static int compat_get_ion_custom_data(
-   struct compat_ion_custom_data __user *data32,
-   struct ion_custom_data __user *data)
-{
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-   int err;
-
-   err = get_user(cmd, >cmd);
-   err |= put_user(cmd, >cmd);
-   err |= get_user(arg, >arg);
-   err |= put_user(arg, >arg);
-
-   return err;
-};
-
 long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
long ret;
@@ -166,23 +143,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
return filp->f_op->unlocked_ioctl(filp, ION_IOC_FREE,
(unsigned long)data);
}
-   case COMPAT_ION_IOC_CUSTOM: {
-   struct compat_ion_custom_data __user *data32;
-   struct ion_custom_data __user *data;
-   int err;
-
-   data32 = compat_ptr(arg);
-   data = compat_alloc_user_space(sizeof(*data));
-   if (!data)
-   return -EFAULT;
-
-   err = compat_get_ion_custom_data(data32, data);
-   if (err)
-   return err;
-
-   return filp->f_op->unlocked_ioctl(filp, ION_IOC_CUSTOM,
-   (unsigned long)data);
-   }
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e096bcd..2b475bf 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -26,7 +26,6 @@ union ion_ioctl_arg {
struct ion_fd_data fd;
struct ion_allocation_data allocation;
struct ion_handle_data handle;
-   struct ion_custom_data custom;
struct ion_heap_query query;
 };
 
@@ -52,7 +51,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
case ION_IOC_FREE:
-   case ION_IOC_CUSTOM:
return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
@@ -62,7 +60,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
struct ion_client *client = filp->private_data;
-   struct ion_device *dev = client->dev;
struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
@@ -145,14 +142,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_CUSTOM:
-   {
-   if (!dev->custom_ioctl)
-   return -ENOTTY;
-   ret = dev->custom_ioctl(client, data.custom.cmd,
-   data.custom.arg);
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8757164..125c537 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/

[PATCHv3 19/22] staging: android: ion: Drop ion_map_kernel interface

2017-04-03 Thread Laura Abbott
Nobody uses this interface externally. Drop it.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
 }
 
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
-   struct ion_buffer *buffer = handle->buffer;
-   void *vaddr;
-
-   if (handle->kmap_cnt) {
-   handle->kmap_cnt++;
-   return buffer->vaddr;
-   }
-   vaddr = ion_buffer_kmap_get(buffer);
-   if (IS_ERR(vaddr))
-   return vaddr;
-   handle->kmap_cnt++;
-   return vaddr;
-}
-
 static void ion_buffer_kmap_put(struct ion_buffer *buffer)
 {
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
 }
 
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-   void *vaddr;
-
-   mutex_lock(>lock);
-   if (!ion_handle_validate(client, handle)) {
-   pr_err("%s: invalid handle passed to map_kernel.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-EINVAL);
-   }
-
-   buffer = handle->buffer;
-
-   if (!handle->buffer->heap->ops->map_kernel) {
-   pr_err("%s: map_kernel is not implemented by this heap.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-ENODEV);
-   }
-
-   mutex_lock(>lock);
-   vaddr = ion_handle_kmap_get(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-   return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-
-   mutex_lock(>lock);
-   buffer = handle->buffer;
-   mutex_lock(>lock);
-   ion_handle_kmap_put(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
 static struct mutex debugfs_mutex;
 static struct rb_root *ion_root_client;
 static int is_client_alive(struct ion_client *client)
-- 
2.7.4



[PATCHv3 14/22] staging: android: ion: Stop butchering the DMA address

2017-04-03 Thread Laura Abbott
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 {
struct ion_buffer *buffer;
struct sg_table *table;
-   struct scatterlist *sg;
-   int i, ret;
+   int ret;
 
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
INIT_LIST_HEAD(>vmas);
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
-   /*
-* 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
-*/
-   for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
-   sg_dma_address(sg) = sg_phys(sg);
-   sg_dma_len(sg) = sg->length;
-   }
mutex_lock(>buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(>buffer_lock);
-- 
2.7.4



[PATCHv3 22/22] staging/android: Update Ion TODO list

2017-04-03 Thread Laura Abbott
Most of the items have been taken care of by a clean up series. Remove
the completed items and add a few new ones.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/TODO | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
index 8f3ac37..5f14247 100644
--- a/drivers/staging/android/TODO
+++ b/drivers/staging/android/TODO
@@ -7,23 +7,10 @@ TODO:
 
 
 ion/
- - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal
-   interface on top of dma-buf. flush_for_device needs to be added to dma-buf
-   first.
- - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some
-   vendor trees. Should be replaced with an ioctl on the dma-buf to expose the
-   begin/end_cpu_access hooks to userspace.
- - Clarify the tricks ion plays with explicitly managing coherency behind the
-   dma api's back (this is absolutely needed for high-perf gpu drivers): Add an
-   explicit coherency management mode to flush_for_device to be used by drivers
-   which want to manage caches themselves and which indicates whether cpu 
caches
-   need flushing.
- - With those removed there's probably no use for ION_IOC_IMPORT anymore either
-   since ion would just be the central allocator for shared buffers.
- - Add dt-binding to expose cma regions as ion heaps, with the rule that any
-   such cma regions must already be used by some device for dma. I.e. ion only
-   exposes existing cma regions and doesn't reserve unecessarily memory when
-   booting a system which doesn't use ion.
+ - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would
+   involve putting appropriate bindings in a memory node for Ion to find.
+ - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
+ - Better test framework (integration with VGEM was suggested)
 
 Please send patches to Greg Kroah-Hartman <g...@kroah.com> and Cc:
 Arve Hjønnevåg <a...@android.com> and Riley Andrews <riandr...@android.com>
-- 
2.7.4



[PATCHv3 20/22] staging: android: ion: Remove ion_handle and ion_client

2017-04-03 Thread Laura Abbott
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c |  53 +--
 drivers/staging/android/ion/ion.c   | 701 ++--
 drivers/staging/android/ion/ion.h   |  77 +---
 drivers/staging/android/uapi/ion.h  |  25 +-
 4 files changed, 51 insertions(+), 805 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
 #include "ion.h"
 
 union ion_ioctl_arg {
-   struct ion_fd_data fd;
struct ion_allocation_data allocation;
-   struct ion_handle_data handle;
struct ion_heap_query query;
 };
 
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_FREE:
-   return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
-   struct ion_client *client = filp->private_data;
-   struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
-   struct ion_handle *handle;
+   int fd;
 
-   handle = ion_alloc(client, data.allocation.len,
+   fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
+   if (fd < 0)
+   return fd;
 
-   data.allocation.handle = handle->id;
+   data.allocation.fd = fd;
 
-   cleanup_handle = handle;
-   break;
-   }
-   case ION_IOC_FREE:
-   {
-   struct ion_handle *handle;
-
-   mutex_lock(>lock);
-   handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   return PTR_ERR(handle);
-   }
-   ion_free_nolock(client, handle);
-   ion_handle_put_nolock(handle);
-   mutex_unlock(>lock);
-   break;
-   }
-   case ION_IOC_SHARE:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
-   if (data.fd.fd < 0)
-   ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
-   ret = ion_query_heaps(client, );
+   ret = ion_query_heaps();
break;
default:
return -ENOTTY;
}
 
if (dir & _IOC_READ) {
-   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
-   if (cleanup_handle)
-   ion_free(client, cleanup_handle);
+   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
return -EFAULT;
-   }
}
return ret;
 }
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 5a82bea..9eeb06f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
-   kref_init(>ref);
 
ret = heap->ops-&g

[PATCHv3 21/22] staging: android: ion: Set query return value

2017-04-03 Thread Laura Abbott
This never got set in the ioctl. Properly set a return value of 0 on
success.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 9eeb06f..d6fd350 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query)
}
 
query->cnt = cnt;
+   ret = 0;
 out:
up_read(>lock);
return ret;
-- 
2.7.4



[PATCHv3 15/22] staging: android: ion: Break the ABI in the name of forward progress

2017-04-03 Thread Laura Abbott
Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Makefile |   3 -
 drivers/staging/android/ion/compat_ion.c | 152 ---
 drivers/staging/android/ion/compat_ion.h |  29 --
 drivers/staging/android/ion/ion-ioctl.c  |   1 -
 drivers/staging/android/ion/ion.c|   5 +-
 drivers/staging/android/uapi/ion.h   |  19 ++--
 6 files changed, 11 insertions(+), 198 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ 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
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 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 
-#include 
-#include 
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs 
*/
-struct compat_ion_allocation_data {
-   compat_size_t len;
-   compat_size_t align;
-   compat_uint_t heap_id_mask;
-   compat_uint_t flags;
-   compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
-   compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC   _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_get_ion_handle_data(
-   struct compat_ion_handle_data __user *data32,
-   struct ion_handle_data __user *data)
-{
-   compat_int_t i;
-   int err;
-
-   err = get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_put_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
-   long ret;
-
-   if (!filp->f_op->unlocked_ioctl)
-   return -ENOTTY;
-
-   switch (cmd) {
-   case COMPAT_ION_IOC_ALLOC:
-   {
-   struct compat_ion_allocation_data __user *data32;
-   

[PATCHv3 08/22] staging: android: ion: Remove crufty cache support

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 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_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,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 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }
 
-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(, 1);
-   sg_set_page(, 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() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,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 != _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_BI

[PATCHv3 12/22] staging: android: ion: Remove old platform support

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig|  42 ---
 drivers/staging/android/ion/Makefile   |   7 -
 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 | 155 ---
 drivers/staging/android/ion/ion_of.c   | 184 -
 drivers/staging/android/ion/ion_of.h   |  37 ---
 drivers/staging/android/ion/ion_test.c | 305 -
 drivers/staging/android/ion/tegra/Makefile |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
 drivers/staging/android/uapi/ion_test.h|  69 -
 12 files changed, 999 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/ion_test.c
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
 delete mode 100644 drivers/staging/android/uapi/ion_test.h

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index c8fb413..206c4de 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,45 +10,3 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
-config ION_TEST
-   tristate "Ion Test Device"
-   depends on ION
-   help
- 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..26672a0 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,13 +1,6 @@
 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_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..000
--- 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..000
--- 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
delet

[PATCHv3 17/22] staging: android: ion: Collapse internal header files

2017-04-03 Thread Laura Abbott
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c |   1 -
 drivers/staging/android/ion/ion.c   |   1 -
 drivers/staging/android/ion/ion.h   | 481 
 drivers/staging/android/ion/ion_carveout_heap.c |   1 -
 drivers/staging/android/ion/ion_chunk_heap.c|   1 -
 drivers/staging/android/ion/ion_cma_heap.c  |   1 -
 drivers/staging/android/ion/ion_heap.c  |   1 -
 drivers/staging/android/ion/ion_page_pool.c |   3 +-
 drivers/staging/android/ion/ion_priv.h  | 453 --
 drivers/staging/android/ion/ion_system_heap.c   |   1 -
 10 files changed, 403 insertions(+), 541 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion_priv.h

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e8a6ffe..67fcb73 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -1,5 +1,5 @@
 /*
- * drivers/staging/android/ion/ion.h
+ * drivers/staging/android/ion/ion_priv.h
  *
  * Copyright (C) 2011 Google, Inc.
  *
@@ -14,24 +14,26 @@
  *
  */
 
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_PRIV_H
+#define _ION_PRIV_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 #include "../uapi/ion.h"
 
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
- * @id:unique identifier for heap.  When allocating higher 
numbers
+ * @id:unique identifier for heap.  When allocating higher 
numb ers
  * will be allocated from first.  At allocation these are passed
  * as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
  * @name:  used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
 };
 
 /**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref:   reference count
+ * @node:  node in the ion_device buffers tree
+ * @dev:   back pointer to the ion_device
+ * @heap:  back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size:  size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @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
+ * @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
+ * @vmas:  list of vma's mapping this buffer
+ * @handle_count:  count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid:   pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+   struct kref ref;
+   union {
+   struct rb_node node;
+   struct list_head list;
+   };
+   struct ion_device *dev;
+   struct ion_heap *heap;
+   unsigned long flags;
+   unsigned long private_flags;
+   size_t size;
+   void *priv_virt;
+   struct mutex lock;
+   int kmap_cnt;
+   void *vaddr;
+   struct sg_table *sg_table;
+   struct page **pages;
+   str

[PATCHv3 18/22] staging: android: ion: Rework heap registration/enumeration

2017-04-03 Thread Laura Abbott
The current model of Ion heap registration  is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig | 25 +
 drivers/staging/android/ion/Makefile|  7 +--
 drivers/staging/android/ion/ion.c   | 28 +--
 drivers/staging/android/ion/ion.h   | 40 +--
 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  | 24 +++--
 drivers/staging/android/ion/ion_heap.c  | 67 -
 drivers/staging/android/ion/ion_system_heap.c   | 38 --
 9 files changed, 85 insertions(+), 163 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+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
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-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
+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
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
 
 #include "ion.h"
 
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
+   struct ion_device *dev = internal_dev;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 
heap->dev = dev;
down_write(>lock);
+   heap->id = heap_id++;
/*
 * use negative heap->id to reverse the priority -- when traversing
 * the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 }
 EXPORT_SYMBOL(ion_device_add_heap);
 
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
 {
 

[PATCHv3 16/22] staging: android: ion: Get rid of ion_phys_addr_t

2017-04-03 Thread Laura Abbott
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.h   | 12 ++--
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  6 +++---
 drivers/staging/android/ion/ion_heap.c  |  4 ++--
 4 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
 struct ion_client;
 struct ion_buffer;
 
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t.  For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
-   ion_phys_addr_t base;
+   phys_addr_t base;
size_t size;
-   ion_phys_addr_t align;
+   phys_addr_t align;
void *priv;
 };
 
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
 struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
 };
 
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
 unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap 
*heap,
return offset;
 }
 
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
  unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
  unsigned long flags)
 {
struct sg_table *table;
-   ion_phys_addr_t paddr;
+   phys_addr_t paddr;
int ret;
 
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
-   ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+   phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
 
ion_heap_buffer_zero(buffer);
 
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
 struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _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 \n", __func__,
-chunk_heap->base, heap_data->size);
+   pr_debug("%s: base %pa size %zu \n", __func__,
+_heap->base, heap_data->size);
 
return _heap->heap;
 
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index c69d0bd..03b554f 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -343,9 +343,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap 
*heap_data)
}
 
if (IS_ERR_OR_NULL(heap)) {
-   pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+   pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
   __func__, heap_data->name, heap_data->type,
-  h

[PATCHv3 11/22] staging: android: ion: Remove duplicate ION_IOC_MAP

2017-04-03 Thread Laura Abbott
ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  |  1 -
 drivers/staging/android/uapi/ion.h   | 10 --
 3 files changed, 12 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index ae1ffc3..5037ddd 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -144,7 +144,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
(unsigned long)data);
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7b54eea..a361724 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -118,7 +118,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
break;
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
{
struct ion_handle *handle;
 
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 3a59044..abd72fd 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -164,16 +164,6 @@ struct ion_heap_query {
 #define ION_IOC_FREE   _IOWR(ION_IOC_MAGIC, 1, struct ion_handle_data)
 
 /**
- * DOC: ION_IOC_MAP - get a file descriptor to mmap
- *
- * Takes an ion_fd_data struct with the handle field populated with a valid
- * opaque handle.  Returns the struct with the fd field set to a file
- * descriptor open in the current address space.  This file descriptor
- * can then be used as an argument to mmap.
- */
-#define ION_IOC_MAP_IOWR(ION_IOC_MAGIC, 2, struct ion_fd_data)
-
-/**
  * DOC: ION_IOC_SHARE - creates a file descriptor to use to share an allocation
  *
  * Takes an ion_fd_data struct with the handle field populated with a valid
-- 
2.7.4



[PATCHv3 00/22] Ion clean up in preparation in moving out of staging

2017-04-03 Thread Laura Abbott
Hi,

This is v3 of the series to do some serious Ion cleanup in preparation for
moving out of staging. I didn't hear much on v2 so I'm going to assume
people are okay with the series as is. I know there were still some open
questions about moving away from /dev/ion but in the interest of small
steps I'd like to go ahead and merge this series assuming there are no more
major objections. More work can happen on top of this.

Changes from v2:
- Dropped the RFC tag
- Minor bisectability fixes
- Sumit's comment about CMA naming
- Updated the TODO list

Thanks,
Laura

Laura Abbott (22):
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  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 custom ioctl interface
  staging: android: ion: Remove import interface
  staging: android: ion: Remove duplicate ION_IOC_MAP
  staging: android: ion: Remove old platform support
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Stop butchering the DMA address
  staging: android: ion: Break the ABI in the name of forward progress
  staging: android: ion: Get rid of ion_phys_addr_t
  staging: android: ion: Collapse internal header files
  staging: android: ion: Rework heap registration/enumeration
  staging: android: ion: Drop ion_map_kernel interface
  staging: android: ion: Remove ion_handle and ion_client
  staging: android: ion: Set query return value
  staging/android: Update Ion TODO list

 arch/powerpc/kvm/book3s_hv_builtin.c   |3 +-
 drivers/base/dma-contiguous.c  |5 +-
 drivers/staging/android/TODO   |   21 +-
 drivers/staging/android/ion/Kconfig|   56 +-
 drivers/staging/android/ion/Makefile   |   18 +-
 drivers/staging/android/ion/compat_ion.c   |  195 
 drivers/staging/android/ion/compat_ion.h   |   29 -
 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|   85 +-
 drivers/staging/android/ion/ion.c  | 1168 +++-
 drivers/staging/android/ion/ion.h  |  389 +--
 drivers/staging/android/ion/ion_carveout_heap.c|   37 +-
 drivers/staging/android/ion/ion_chunk_heap.c   |   27 +-
 drivers/staging/android/ion/ion_cma_heap.c |  125 +--
 drivers/staging/android/ion/ion_dummy_driver.c |  155 ---
 drivers/staging/android/ion/ion_heap.c |   68 --
 drivers/staging/android/ion/ion_of.c   |  184 ---
 drivers/staging/android/ion/ion_of.h   |   37 -
 drivers/staging/android/ion/ion_page_pool.c|6 +-
 drivers/staging/android/ion/ion_priv.h |  473 
 drivers/staging/android/ion/ion_system_heap.c  |   53 +-
 drivers/staging/android/ion/ion_test.c |  305 -
 drivers/staging/android/ion/tegra/Makefile |1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |   80 --
 drivers/staging/android/uapi/ion.h |   86 +-
 drivers/staging/android/uapi/ion_test.h|   69 --
 include/linux/cma.h|6 +-
 mm/cma.c   |   31 +-
 mm/cma.h   |1 +
 mm/cma_debug.c |2 +-
 32 files changed, 620 insertions(+), 3214 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h
 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/ion_priv.h
 delete mode 100644 drivers/staging/android/ion/ion_test.c
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
 delete mode 100644 drivers/staging/android/uapi/ion_test.h

-- 
2.7.4



[PATCHv3 05/22] staging: android: ion: Duplicate sg_table

2017-04-03 Thread Laura Abbott
Ion currently returns a single sg_table on each dma_map call. This is
incorrect for later usage.

Signed-off-by: Laura Abbott <labb...@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 c2adfe1..7dcb8a9 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -800,6 +800,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(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);
+   }
+
+   return new_table;
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
@@ -807,13 +833,15 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
 
ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
+   sg_free_table(table);
+   kfree(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-- 
2.7.4



[RFC PATCHv2 15/21] staging: android: ion: Break the ABI in the name of forward progress

2017-03-17 Thread Laura Abbott
To: Sumit Semwal <sumit.sem...@linaro.org>
To: Riley Andrews <riandr...@android.com>
Cc: rom...@google.com
To: a...@android.com
To: Riley Andrews <riandr...@android.com>
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: Brian Starkey <brian.star...@arm.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Mark Brown <broo...@kernel.org>
Cc: Benjamin Gaignard <benjamin.gaign...@linaro.org>
Cc: linux...@kvack.org
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>


Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Makefile |   3 -
 drivers/staging/android/ion/compat_ion.c | 152 ---
 drivers/staging/android/ion/compat_ion.h |  29 --
 drivers/staging/android/ion/ion-ioctl.c  |   1 -
 drivers/staging/android/ion/ion.c|   5 +-
 drivers/staging/android/uapi/ion.h   |  19 ++--
 6 files changed, 11 insertions(+), 198 deletions(-)
 delete mode 100644 drivers/staging/android/ion/compat_ion.c
 delete mode 100644 drivers/staging/android/ion/compat_ion.h

diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ 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
 obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 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 
-#include 
-#include 
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs 
*/
-struct compat_ion_allocation_data {
-   compat_size_t len;
-   compat_size_t align;
-   compat_uint_t heap_id_mask;
-   compat_uint_t flags;
-   compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
-   compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC   _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err = get_user(s, >len);
-   err |= put_user(s, >len);
-   err |= get_user(s, >align);
-   err |= put_user(s, >align);
-   err |= get_user(u, >heap_id_mask);
-   err |= put_user(u, >heap_id_mask);
-   err |= get_user(u, >flags);
-   err |= put_user(u, >flags);
-   err |= get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_get_ion_handle_data(
-   struct compat_ion_handle_data __user *data32,
-   struct ion_handle_data __user *data)
-{
-   compat_int_t i;
-   int err;
-
-   err = get_user(i, >handle);
-   err |= put_user(i, >handle);
-
-   return err;
-}
-
-static int compat_put_ion_allocation_data(
-   struct compat_ion_allocation_data __user *data32,
-   struct ion_allocation_data __user *data)
-{
-   compat_size_t s;
-   compat_uint_t u;
-   compat_int_t i;
-   int err;
-
-   err 

[RFC PATCHv2 16/21] staging: android: ion: Get rid of ion_phys_addr_t

2017-03-17 Thread Laura Abbott

Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.h   | 12 ++--
 drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
 drivers/staging/android/ion/ion_chunk_heap.c|  6 +++---
 drivers/staging/android/ion/ion_heap.c  |  4 ++--
 4 files changed, 12 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
 struct ion_client;
 struct ion_buffer;
 
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t.  For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
-   ion_phys_addr_t base;
+   phys_addr_t base;
size_t size;
-   ion_phys_addr_t align;
+   phys_addr_t align;
void *priv;
 };
 
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c 
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
 struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
 };
 
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
 unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap 
*heap,
return offset;
 }
 
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
  unsigned long size)
 {
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
  unsigned long flags)
 {
struct sg_table *table;
-   ion_phys_addr_t paddr;
+   phys_addr_t paddr;
int ret;
 
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
-   ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+   phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
 
ion_heap_buffer_zero(buffer);
 
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c 
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
 struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
-   ion_phys_addr_t base;
+   phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct 
ion_platform_heap *heap_data)
chunk_heap->heap.ops = _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 \n", __func__,
-chunk_heap->base, heap_data->size);
+   pr_debug("%s: base %pa size %zu \n", __func__,
+_heap->base, heap_data->size);
 
return _heap->heap;
 
diff --git a/drivers/staging/android/ion/ion_heap.c 
b/drivers/staging/android/ion/ion_heap.c
index c69d0bd..03b554f 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -343,9 +343,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap 
*heap_data)
}
 
if (IS_ERR_OR_NULL(heap)) {
-   pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+   pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
   __func__, heap_data->name, heap_data->type,
-  h

[RFC PATCHv2 10/21] staging: android: ion: Remove import interface

2017-03-17 Thread Laura Abbott

With the expansion of dma-buf and the move for Ion to be come just an
allocator, the import mechanism is mostly useless. There isn't a kernel
component to Ion anymore and handles are private to Ion. Remove this
interface.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  | 11 -
 drivers/staging/android/ion/ion.c| 76 
 drivers/staging/android/uapi/ion.h   |  9 
 4 files changed, 97 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 5b192ea..ae1ffc3 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -145,7 +145,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
case ION_IOC_SHARE:
case ION_IOC_MAP:
-   case ION_IOC_IMPORT:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 2b475bf..7b54eea 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -131,17 +131,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
ret = data.fd.fd;
break;
}
-   case ION_IOC_IMPORT:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_import_dma_buf_fd(client, data.fd.fd);
-   if (IS_ERR(handle))
-   ret = PTR_ERR(handle);
-   else
-   data.handle.handle = handle->id;
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 125c537..3d979ef5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,24 +274,6 @@ int ion_handle_put(struct ion_handle *handle)
return ret;
 }
 
-static struct ion_handle *ion_handle_lookup(struct ion_client *client,
-   struct ion_buffer *buffer)
-{
-   struct rb_node *n = client->handles.rb_node;
-
-   while (n) {
-   struct ion_handle *entry = rb_entry(n, struct ion_handle, node);
-
-   if (buffer < entry->buffer)
-   n = n->rb_left;
-   else if (buffer > entry->buffer)
-   n = n->rb_right;
-   else
-   return entry;
-   }
-   return ERR_PTR(-EINVAL);
-}
-
 struct ion_handle *ion_handle_get_by_id_nolock(struct ion_client *client,
   int id)
 {
@@ -1023,64 +1005,6 @@ int ion_share_dma_buf_fd(struct ion_client *client, 
struct ion_handle *handle)
 }
 EXPORT_SYMBOL(ion_share_dma_buf_fd);
 
-struct ion_handle *ion_import_dma_buf(struct ion_client *client,
- struct dma_buf *dmabuf)
-{
-   struct ion_buffer *buffer;
-   struct ion_handle *handle;
-   int ret;
-
-   /* if this memory came from ion */
-
-   if (dmabuf->ops != _buf_ops) {
-   pr_err("%s: can not import dmabuf from another exporter\n",
-  __func__);
-   return ERR_PTR(-EINVAL);
-   }
-   buffer = dmabuf->priv;
-
-   mutex_lock(>lock);
-   /* if a handle exists for this buffer just take a reference to it */
-   handle = ion_handle_lookup(client, buffer);
-   if (!IS_ERR(handle)) {
-   ion_handle_get(handle);
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   handle = ion_handle_create(client, buffer);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   goto end;
-   }
-
-   ret = ion_handle_add(client, handle);
-   mutex_unlock(>lock);
-   if (ret) {
-   ion_handle_put(handle);
-   handle = ERR_PTR(ret);
-   }
-
-end:
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf);
-
-struct ion_handle *ion_import_dma_buf_fd(struct ion_client *client, int fd)
-{
-   struct dma_buf *dmabuf;
-   struct ion_handle *handle;
-
-   dmabuf = dma_buf_get(fd);
-   if (IS_ERR(dmabuf))
-   return ERR_CAST(dmabuf);
-
-   handle = ion_import_dma_buf(client, dmabuf);
-   dma_buf_put(dmabuf);
-   return handle;
-}
-EXPORT_SYMBOL(ion_import_dma_buf_fd);
-
 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/uapi/ion.h 
b/drivers/staging/android/uap

[RFC PATCHv2 20/21] staging: android: ion: Remove ion_handle and ion_client

2017-03-17 Thread Laura Abbott

ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c |  53 +--
 drivers/staging/android/ion/ion.c   | 697 ++--
 drivers/staging/android/ion/ion.h   |  73 +---
 drivers/staging/android/uapi/ion.h  |  25 +-
 4 files changed, 49 insertions(+), 799 deletions(-)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
 #include "ion.h"
 
 union ion_ioctl_arg {
-   struct ion_fd_data fd;
struct ion_allocation_data allocation;
-   struct ion_handle_data handle;
struct ion_heap_query query;
 };
 
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_FREE:
-   return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
-   struct ion_client *client = filp->private_data;
-   struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
-   struct ion_handle *handle;
+   int fd;
 
-   handle = ion_alloc(client, data.allocation.len,
+   fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
+   if (fd < 0)
+   return fd;
 
-   data.allocation.handle = handle->id;
+   data.allocation.fd = fd;
 
-   cleanup_handle = handle;
-   break;
-   }
-   case ION_IOC_FREE:
-   {
-   struct ion_handle *handle;
-
-   mutex_lock(>lock);
-   handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
-   if (IS_ERR(handle)) {
-   mutex_unlock(>lock);
-   return PTR_ERR(handle);
-   }
-   ion_free_nolock(client, handle);
-   ion_handle_put_nolock(handle);
-   mutex_unlock(>lock);
-   break;
-   }
-   case ION_IOC_SHARE:
-   {
-   struct ion_handle *handle;
-
-   handle = ion_handle_get_by_id(client, data.handle.handle);
-   if (IS_ERR(handle))
-   return PTR_ERR(handle);
-   data.fd.fd = ion_share_dma_buf_fd(client, handle);
-   ion_handle_put(handle);
-   if (data.fd.fd < 0)
-   ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
-   ret = ion_query_heaps(client, );
+   ret = ion_query_heaps();
break;
default:
return -ENOTTY;
}
 
if (dir & _IOC_READ) {
-   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd))) {
-   if (cleanup_handle)
-   ion_free(client, cleanup_handle);
+   if (copy_to_user((void __user *)arg, , _IOC_SIZE(cmd)))
return -EFAULT;
-   }
}
return ret;
 }
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 5a82bea..64c652b 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 
buffer->heap = heap;
buffer->flags = flags;
-   kref_init(>ref);
 
ret = heap->ops-&g

[RFC PATCHv2 18/21] staging: android: ion: Rework heap registration/enumeration

2017-03-17 Thread Laura Abbott

The current model of Ion heap registration  is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig | 25 +
 drivers/staging/android/ion/Makefile|  7 +--
 drivers/staging/android/ion/ion.c   | 28 +--
 drivers/staging/android/ion/ion.h   | 40 +--
 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  | 24 +++--
 drivers/staging/android/ion/ion_heap.c  | 67 -
 drivers/staging/android/ion/ion_system_heap.c   | 38 --
 9 files changed, 85 insertions(+), 163 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
+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
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-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
+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
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
 
 #include "ion.h"
 
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
 DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
 
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
 {
struct dentry *debug_file;
+   struct ion_device *dev = internal_dev;
 
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 
heap->dev = dev;
down_write(>lock);
+   heap->id = heap_id++;
/*
 * use negative heap->id to reverse the priority -- when traversing
 * the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct 
ion_heap *heap)
 }
 EXPORT_SYMBOL(ion_device_add_heap);
 
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
 {
 

[RFC PATCHv2 12/21] staging: android: ion: Remove old platform support

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig|  42 ---
 drivers/staging/android/ion/Makefile   |   7 -
 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/ion_test.c | 305 -
 drivers/staging/android/ion/tegra/Makefile |   1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |  80 --
 drivers/staging/android/uapi/ion_test.h|  69 -
 12 files changed, 1000 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/ion_test.c
 delete mode 100644 drivers/staging/android/ion/tegra/Makefile
 delete mode 100644 drivers/staging/android/ion/tegra/tegra_ion.c
 delete mode 100644 drivers/staging/android/uapi/ion_test.h

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index c8fb413..206c4de 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,45 +10,3 @@ menuconfig ION
  If you're not using Android its probably safe to
  say N here.
 
-config ION_TEST
-   tristate "Ion Test Device"
-   depends on ION
-   help
- 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..26672a0 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,13 +1,6 @@
 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_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..000
--- 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..000
--- 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
delet

[RFC PATCHv2 11/21] staging: android: ion: Remove duplicate ION_IOC_MAP

2017-03-17 Thread Laura Abbott

ION_IOC_MAP is the same as ION_IOC_SHARE. We really don't need two
identical interfaces. Remove it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c |  1 -
 drivers/staging/android/ion/ion-ioctl.c  |  1 -
 drivers/staging/android/uapi/ion.h   | 10 --
 3 files changed, 12 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index ae1ffc3..5037ddd 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -144,7 +144,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
(unsigned long)data);
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 7b54eea..a361724 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -118,7 +118,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
break;
}
case ION_IOC_SHARE:
-   case ION_IOC_MAP:
{
struct ion_handle *handle;
 
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 3a59044..abd72fd 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -164,16 +164,6 @@ struct ion_heap_query {
 #define ION_IOC_FREE   _IOWR(ION_IOC_MAGIC, 1, struct ion_handle_data)
 
 /**
- * DOC: ION_IOC_MAP - get a file descriptor to mmap
- *
- * Takes an ion_fd_data struct with the handle field populated with a valid
- * opaque handle.  Returns the struct with the fd field set to a file
- * descriptor open in the current address space.  This file descriptor
- * can then be used as an argument to mmap.
- */
-#define ION_IOC_MAP_IOWR(ION_IOC_MAGIC, 2, struct ion_fd_data)
-
-/**
  * DOC: ION_IOC_SHARE - creates a file descriptor to use to share an allocation
  *
  * Takes an ion_fd_data struct with the handle field populated with a valid
-- 
2.7.4



[RFC PATCHv2 19/21] staging: android: ion: Drop ion_map_kernel interface

2017-03-17 Thread Laura Abbott

Nobody uses this interface externally. Drop it.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
 }
 
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
-   struct ion_buffer *buffer = handle->buffer;
-   void *vaddr;
-
-   if (handle->kmap_cnt) {
-   handle->kmap_cnt++;
-   return buffer->vaddr;
-   }
-   vaddr = ion_buffer_kmap_get(buffer);
-   if (IS_ERR(vaddr))
-   return vaddr;
-   handle->kmap_cnt++;
-   return vaddr;
-}
-
 static void ion_buffer_kmap_put(struct ion_buffer *buffer)
 {
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
 }
 
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-   void *vaddr;
-
-   mutex_lock(>lock);
-   if (!ion_handle_validate(client, handle)) {
-   pr_err("%s: invalid handle passed to map_kernel.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-EINVAL);
-   }
-
-   buffer = handle->buffer;
-
-   if (!handle->buffer->heap->ops->map_kernel) {
-   pr_err("%s: map_kernel is not implemented by this heap.\n",
-  __func__);
-   mutex_unlock(>lock);
-   return ERR_PTR(-ENODEV);
-   }
-
-   mutex_lock(>lock);
-   vaddr = ion_handle_kmap_get(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-   return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
-   struct ion_buffer *buffer;
-
-   mutex_lock(>lock);
-   buffer = handle->buffer;
-   mutex_lock(>lock);
-   ion_handle_kmap_put(handle);
-   mutex_unlock(>lock);
-   mutex_unlock(>lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
 static struct mutex debugfs_mutex;
 static struct rb_root *ion_root_client;
 static int is_client_alive(struct ion_client *client)
-- 
2.7.4



[RFC PATCHv2 03/21] staging: android: ion: Remove dmap_cnt

2017-03-17 Thread Laura Abbott

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

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

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



[RFC PATCHv2 05/21] staging: android: ion: Duplicate sg_table

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 c2adfe1..7dcb8a9 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -800,6 +800,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(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);
+   }
+
+   return new_table;
+}
+
 static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
enum dma_data_direction direction)
 {
@@ -807,13 +833,15 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
 
ion_buffer_sync_for_device(buffer, attachment->dev, direction);
-   return buffer->sg_table;
+   return dup_sg_table(buffer->sg_table);
 }
 
 static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
  struct sg_table *table,
  enum dma_data_direction direction)
 {
+   sg_free_table(table);
+   kfree(table);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
-- 
2.7.4



[RFC PATCHv2 04/21] staging: android: ion: Remove alignment from allocation field

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 f45115f..c2adfe1 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -103,7 +103,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;
@@ -119,15 +118,14 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
buffer->flags = flags;
kref_init(>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;
}
@@ -401,7 +399,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;
@@ -410,8 +408,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
@@ -428,7 +426,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 - allocat

[RFC PATCHv2 14/21] staging: android: ion: Stop butchering the DMA address

2017-03-17 Thread Laura Abbott

Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c | 17 +
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
 {
struct ion_buffer *buffer;
struct sg_table *table;
-   struct scatterlist *sg;
-   int i, ret;
+   int ret;
 
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct 
ion_heap *heap,
INIT_LIST_HEAD(>vmas);
INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
-   /*
-* 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
-*/
-   for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
-   sg_dma_address(sg) = sg_phys(sg);
-   sg_dma_len(sg) = sg->length;
-   }
mutex_lock(>buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(>buffer_lock);
-- 
2.7.4



[RFC PATCHv2 13/21] staging: android: ion: Use CMA APIs directly

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/Kconfig|  7 +++
 drivers/staging/android/ion/Makefile   |  3 +-
 drivers/staging/android/ion/ion_cma_heap.c | 97 --
 3 files changed, 35 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
  If you're not using Android its probably safe to
  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 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
 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
+   ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
 ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #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, GFP_KERNEL);
+   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 = t

[RFC PATCHv2 01/21] cma: Store a name in the cma structure

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 b55804c..ea9726e 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;
 
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
 
-   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
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 03f32d0..d41d1f8 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,
  gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..0d187b1 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 ffc0c3d..595b757 100644
--- a/mm/cma_debug.c
+++ b/mm/cma_debug.c
@@ -167,7 +167,7 @@ static void cma_debugfs_add_one(

[RFC PATCHv2 06/21] staging: android: ion: Call dma_map_sg for syncing and mapping

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c  | 151 ++---
 drivers/staging/android/ion/ion_priv.h |   1 +
 2 files changed, 103 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 7dcb8a9..6aac935 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -162,6 +162,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap 
*heap,
buffer->dev = dev;
buffer->size = len;
INIT_LIST_HEAD(>vmas);
+   INIT_LIST_HEAD(>attachments);
mutex_init(>lock);
/*
 * this will set up dma addresses for the sglist -- it is not
@@ -796,10 +797,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;
@@ -826,22 +823,89 @@ 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);
+}
+
+struct ion_dma_buf_attachment {
+   struct device *dev;
+   struct sg_table *table;
+   struct list_head list;
+};
+
+static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a;
+   struct sg_table *table;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   table = dup_sg_table(buffer->sg_table);
+   if (IS_ERR(table)) {
+   kfree(a);
+   return -ENOMEM;
+   }
+
+   a->table = table;
+   a->dev = dev;
+   INIT_LIST_HEAD(>list);
+
+   attachment->priv = a;
+
+   mutex_lock(>lock);
+   list_add(>list, >attachments);
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static void ion_dma_buf_detatch(struct dma_buf *dmabuf,
+   struct dma_buf_attachment *attachment)
+{
+   struct ion_dma_buf_attachment *a = attachment->priv;
+   struct ion_buffer *buffer = dmabuf->priv;
+
+   free_duped_table(a->table);
+   mutex_lock(>lock);
+   list_del(>list);
+   mutex_unlock(>lock);
+
+   kfree(a);
+}
+
+
 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 ion_dma_buf_attachment *a = attachment->priv;
+   struct sg_table *table;
+   int ret;
+
+   table = a->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;
+   }
+   return table;
+
+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);
 }
 
 void ion_pages_sync_for_device(struct device *dev, struct page *page,
@@ -865,38 +929,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(>lock);
-   for (i = 0; i < pages; i++) {
-   struct page *page = buffer->pages[i];
-
-   if (ion_buffer_page_is_dirty(page))
-

[RFC PATCHv2 09/21] staging: android: ion: Remove custom ioctl interface

2017-03-17 Thread Laura Abbott

Ion is now moving towards a unified interfact. This makes the custom
ioctl interface unneeded. Remove it.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c | 40 
 drivers/staging/android/ion/ion-ioctl.c  | 11 -
 drivers/staging/android/ion/ion.c|  6 +
 drivers/staging/android/ion/ion_priv.h   |  8 +--
 drivers/staging/android/uapi/ion.h   | 21 -
 5 files changed, 2 insertions(+), 84 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index b892d3a..5b192ea 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -30,11 +30,6 @@ struct compat_ion_allocation_data {
compat_int_t handle;
 };
 
-struct compat_ion_custom_data {
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-};
-
 struct compat_ion_handle_data {
compat_int_t handle;
 };
@@ -43,8 +38,6 @@ struct compat_ion_handle_data {
  struct compat_ion_allocation_data)
 #define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
  struct compat_ion_handle_data)
-#define COMPAT_ION_IOC_CUSTOM  _IOWR(ION_IOC_MAGIC, 6, \
- struct compat_ion_custom_data)
 
 static int compat_get_ion_allocation_data(
struct compat_ion_allocation_data __user *data32,
@@ -105,22 +98,6 @@ static int compat_put_ion_allocation_data(
return err;
 }
 
-static int compat_get_ion_custom_data(
-   struct compat_ion_custom_data __user *data32,
-   struct ion_custom_data __user *data)
-{
-   compat_uint_t cmd;
-   compat_ulong_t arg;
-   int err;
-
-   err = get_user(cmd, >cmd);
-   err |= put_user(cmd, >cmd);
-   err |= get_user(arg, >arg);
-   err |= put_user(arg, >arg);
-
-   return err;
-};
-
 long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
long ret;
@@ -166,23 +143,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
return filp->f_op->unlocked_ioctl(filp, ION_IOC_FREE,
(unsigned long)data);
}
-   case COMPAT_ION_IOC_CUSTOM: {
-   struct compat_ion_custom_data __user *data32;
-   struct ion_custom_data __user *data;
-   int err;
-
-   data32 = compat_ptr(arg);
-   data = compat_alloc_user_space(sizeof(*data));
-   if (!data)
-   return -EFAULT;
-
-   err = compat_get_ion_custom_data(data32, data);
-   if (err)
-   return err;
-
-   return filp->f_op->unlocked_ioctl(filp, ION_IOC_CUSTOM,
-   (unsigned long)data);
-   }
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index e096bcd..2b475bf 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -26,7 +26,6 @@ union ion_ioctl_arg {
struct ion_fd_data fd;
struct ion_allocation_data allocation;
struct ion_handle_data handle;
-   struct ion_custom_data custom;
struct ion_heap_query query;
 };
 
@@ -52,7 +51,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
case ION_IOC_FREE:
-   case ION_IOC_CUSTOM:
return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
@@ -62,7 +60,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
 long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 {
struct ion_client *client = filp->private_data;
-   struct ion_device *dev = client->dev;
struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
@@ -145,14 +142,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
data.handle.handle = handle->id;
break;
}
-   case ION_IOC_CUSTOM:
-   {
-   if (!dev->custom_ioctl)
-   return -ENOTTY;
-   ret = dev->custom_ioctl(client, data.custom.cmd,
-   data.custom.arg);
-   break;
-   }
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(client, );
break;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 8757164..125c537 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1347,10 +1347,7 @@ void ion_device_add_heap(s

[RFC PATCHv2 07/21] staging: android: ion: Remove page faulting support

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 6aac935..226ea1f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -42,37 +42,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)
@@ -140,25 +114,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(>vmas);
@@ -924,69 +879,6 @@ void ion_pages_sync_for_device(struct device *dev, struct 
page *page,
dma_sync_sg_for_device(dev, , 1, dir);
 }
 
-struct ion_vma_list {
-   struct list_head list;
-   struct vm_area_struct *vma;
-};
-
-static int ion_vm_fault(struct vm_fault *vmf)
-{
-   struct ion_buffer *buffer = vmf->vma->vm_private_data;
-   unsigned long pfn;
-   int ret;
-
-   mutex_lock(>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(vmf->vma, vmf->address, pfn);
-   mutex_unlock(>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(>lock);
-   list_add(_list->list, >vmas);
-   mutex_unlock(>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(>lock);
-   list_for_each_entry_safe(vma_list, tmp, >vmas, list) {
-   if (vma_list->vma != vma)
-   continue;
-   list_del(_list->list);
-   kfree(vma_list);
-   pr_debug("%s: deleting %p\n", __func__, vma);
-   break;
-   }
-   mutex_unlock(>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;
@@ -998,15 +890,6 @@ static int ion_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   if (ion_buffer_fault_user_mappings(buffer)) {
- 

[RFC PATCHv2 17/21] staging: android: ion: Collapse internal header files

2017-03-17 Thread Laura Abbott

Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion-ioctl.c |   1 -
 drivers/staging/android/ion/ion.c   |   1 -
 drivers/staging/android/ion/ion.h   | 481 
 drivers/staging/android/ion/ion_carveout_heap.c |   1 -
 drivers/staging/android/ion/ion_chunk_heap.c|   1 -
 drivers/staging/android/ion/ion_cma_heap.c  |   1 -
 drivers/staging/android/ion/ion_heap.c  |   1 -
 drivers/staging/android/ion/ion_page_pool.c |   3 +-
 drivers/staging/android/ion/ion_priv.h  | 453 --
 drivers/staging/android/ion/ion_system_heap.c   |   1 -
 10 files changed, 403 insertions(+), 541 deletions(-)
 delete mode 100644 drivers/staging/android/ion/ion_priv.h

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
 #include 
 
 #include "ion.h"
-#include "ion_priv.h"
 
 bool ion_buffer_cached(struct ion_buffer *buffer)
 {
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index e8a6ffe..67fcb73 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -1,5 +1,5 @@
 /*
- * drivers/staging/android/ion/ion.h
+ * drivers/staging/android/ion/ion_priv.h
  *
  * Copyright (C) 2011 Google, Inc.
  *
@@ -14,24 +14,26 @@
  *
  */
 
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_PRIV_H
+#define _ION_PRIV_H
 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
 
 #include "../uapi/ion.h"
 
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
 /**
  * struct ion_platform_heap - defines a heap in the given platform
  * @type:  type of the heap from ion_heap_type enum
- * @id:unique identifier for heap.  When allocating higher 
numbers
+ * @id:unique identifier for heap.  When allocating higher 
numb ers
  * will be allocated from first.  At allocation these are passed
  * as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
  * @name:  used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
 };
 
 /**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref:   reference count
+ * @node:  node in the ion_device buffers tree
+ * @dev:   back pointer to the ion_device
+ * @heap:  back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size:  size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @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
+ * @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
+ * @vmas:  list of vma's mapping this buffer
+ * @handle_count:  count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid:   pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+   struct kref ref;
+   union {
+   struct rb_node node;
+   struct list_head list;
+   };
+   struct ion_device *dev;
+   struct ion_heap *heap;
+   unsigned long flags;
+   unsigned long private_flags;
+   size_t size;
+   void *priv_virt;
+   struct mutex lock;
+   int kmap_cnt;
+   void *vaddr;
+   struct sg_table *sg_table;
+   struct page **pages;
+   str

[RFC PATCHv2 08/21] staging: android: ion: Remove crufty cache support

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/compat_ion.c|  1 -
 drivers/staging/android/ion/ion-ioctl.c |  6 
 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_priv.h  | 13 
 drivers/staging/android/ion/ion_system_heap.c   |  5 
 drivers/staging/android/uapi/ion.h  | 10 ---
 9 files changed, 90 deletions(-)

diff --git a/drivers/staging/android/ion/compat_ion.c 
b/drivers/staging/android/ion/compat_ion.c
index 9a978d2..b892d3a 100644
--- a/drivers/staging/android/ion/compat_ion.c
+++ b/drivers/staging/android/ion/compat_ion.c
@@ -186,7 +186,6 @@ long compat_ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
case ION_IOC_SHARE:
case ION_IOC_MAP:
case ION_IOC_IMPORT:
-   case ION_IOC_SYNC:
return filp->f_op->unlocked_ioctl(filp, cmd,
(unsigned long)compat_ptr(arg));
default:
diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 5b2e93f..e096bcd 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -51,7 +51,6 @@ static int validate_ioctl_arg(unsigned int cmd, union 
ion_ioctl_arg *arg)
 static unsigned int ion_ioctl_dir(unsigned int cmd)
 {
switch (cmd) {
-   case ION_IOC_SYNC:
case ION_IOC_FREE:
case ION_IOC_CUSTOM:
return _IOC_WRITE;
@@ -146,11 +145,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 226ea1f..8757164 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -863,22 +863,6 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
*attachment,
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
 }
 
-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(, 1);
-   sg_set_page(, 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() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 1, dir);
-}
-
 static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
 {
struct ion_buffer *buffer = dmabuf->priv;
@@ -1097,30 +1081,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 != _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_BI

[RFC PATCHv2 02/21] cma: Introduce cma_for_each_area

2017-03-17 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base, 
phys_addr_t size,
 extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int 
align,
  gfp_t gfp_mask);
 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 0d187b1..9a040e1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -498,3 +498,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(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4



[RFC PATCHv2 21/21] staging: android: ion: Set query return value

2017-03-17 Thread Laura Abbott

This never got set in the ioctl. Properly set a return value of 0 on
success.

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

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 64c652b..8bd90ce 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query)
}
 
query->cnt = cnt;
+   ret = 0;
 out:
up_read(>lock);
return ret;
-- 
2.7.4



[RFC PATCHv2 00/21] Ion clean in preparation for moving out of staging

2017-03-17 Thread Laura Abbott

Hi,

This is v2 of the series to do some serious Ion clean up in preparation for
moving out of staging. I got good feedback last time so this series mostly
attempts to address that feedback and do more still more cleanup. Highlights:

- All calls to DMA APIs should now be with a real actual proper device
  structure
- Patch to stop setting sg_dma_address manually now included
- Fix for a bug in the query interface
- Removal of custom ioctl interface
- Removal of import interface
- Removal of any notion of using Ion as an in kernel interface.
- Cleanup of ABI so compat interface is no longer needed
- Deletion of a bit more platform code
- Combined heap enumeration and heap registration code up so there are fewer
  layers of abstraction
- Some general cleanup and header reduction.
- Removal of both the ion_client and ion_handle structures since these mostly
  become redundant. As a result, Ion only returns a dma_buf fd. The overall
  result is that the only Ion interfaces are the query ioctl and the alloc
  ioctl.

The following are still TODOs/open problems:
- Sumit's comments about the CMA naming.
- Bindings/platform for chunk and carveout heap
- There was some discussion about making the sg_table duplication generic. I
  got bogged down in handling some of the edge cases for generic handling
  so I put this aside. Making it generic is still something that should happen.
- More fine-grained support for restricting heap access. There are good
  arguments to be made for having a way for having good integration with
  selinux and other policy mechanisms.
- While not on the original list, there is still no good good test standalone
  test framework. I noticed that the existing ion_test was fairly generic so I
  proposed moving it to dma_buf. Daniel Vetter suggested just using the VGEM
  module instead. Ideally, the tests can live as part of some other existing
  test set (drm tests maybe?)

Feedback appreciated as always.

Thanks,
Laura

Laura Abbott (21):
  cma: Store a name in the cma structure
  cma: Introduce cma_for_each_area
  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 custom ioctl interface
  staging: android: ion: Remove import interface
  staging: android: ion: Remove duplicate ION_IOC_MAP
  staging: android: ion: Remove old platform support
  staging: android: ion: Use CMA APIs directly
  staging: android: ion: Stop butchering the DMA address
  staging: android: ion: Break the ABI in the name of forward progress
  staging: android: ion: Get rid of ion_phys_addr_t
  staging: android: ion: Collapse internal header files
  staging: android: ion: Rework heap registration/enumeration
  staging: android: ion: Drop ion_map_kernel interface
  staging: android: ion: Remove ion_handle and ion_client
  staging: android: ion: Set query return value

 drivers/base/dma-contiguous.c  |5 +-
 drivers/staging/android/ion/Kconfig|   56 +-
 drivers/staging/android/ion/Makefile   |   18 +-
 drivers/staging/android/ion/compat_ion.c   |  195 
 drivers/staging/android/ion/compat_ion.h   |   29 -
 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|   85 +-
 drivers/staging/android/ion/ion.c  | 1164 +++-
 drivers/staging/android/ion/ion.h  |  393 +--
 drivers/staging/android/ion/ion_carveout_heap.c|   37 +-
 drivers/staging/android/ion/ion_chunk_heap.c   |   27 +-
 drivers/staging/android/ion/ion_cma_heap.c |  125 +--
 drivers/staging/android/ion/ion_dummy_driver.c |  156 ---
 drivers/staging/android/ion/ion_heap.c |   68 --
 drivers/staging/android/ion/ion_of.c   |  184 
 drivers/staging/android/ion/ion_of.h   |   37 -
 drivers/staging/android/ion/ion_page_pool.c|6 +-
 drivers/staging/android/ion/ion_priv.h |  473 
 drivers/staging/android/ion/ion_system_heap.c  |   53 +-
 drivers/staging/android/ion/ion_test.c |  305 -
 drivers/staging/android/ion/tegra/Makefile |1 -
 drivers/staging/android/ion/tegra/tegra_ion.c  |   80 --
 drivers/staging/android/uapi/ion.h |   86 +-
 drivers/staging/android/uapi/ion_test.h|   69 --
 include/linux/cma.h|6 +-
 mm/cma.c   |   25 +-
 mm/cma.h   |1 +
 mm/cma_debug.c |2 +-
 30

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

2017-03-17 Thread Laura Abbott
On 03/10/2017 12:53 AM, Sumit Semwal wrote:
> Hi Laura,
> 
> Thanks for the patch.
> 
> On 3 March 2017 at 03:14, Laura Abbott <labb...@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 <labb...@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(-)
>>
> 
>> +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.
> 



Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module

2017-03-14 Thread Laura Abbott
On 03/14/2017 01:13 PM, Daniel Vetter wrote:
> On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
>>
>> dma-buf is designed to share buffers. Sharing means that there needs to
>> be another subsystem to accept those buffers. Introduce a simple test
>> module to act as a dummy system to accept dma_bufs from elsewhere. The
>> goal is to provide a very simple interface to validate exported buffers
>> do something reasonable. This is based on ion_test.c that existed for
>> the Ion framework.
>>
>> Signed-off-by: Laura Abbott <labb...@redhat.com>
>> ---
>> This is basically a drop in of what was available as
>> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
>> parts it might be useful as a more general test module. RFC mostly
>> to see if this is generally useful or not.
> 
> We already have a test dma-buf driver, which also handles reservation
> objects and can create fences to provoke signalling races an all kinds of
> other fun. It's drivers/gpu/drm/vgem.
> 
> If there's anything missing in there, patches very much welcome.
> -Daniel
> 

Thanks for that pointer. It certainly looks more complete vs. allocating
a platform_device. I'll look and see if there's anything that needs
extension. Plus this means I can probably delete more code from Ion (woo)

Thanks,
Laura

>> ---
>>  drivers/dma-buf/Kconfig   |   9 ++
>>  drivers/dma-buf/Makefile  |   1 +
>>  drivers/dma-buf/dma-buf-test.c| 309 
>> ++
>>  include/uapi/linux/dma_buf_test.h |  67 +
>>  4 files changed, 386 insertions(+)
>>  create mode 100644 drivers/dma-buf/dma-buf-test.c
>>  create mode 100644 include/uapi/linux/dma_buf_test.h
>>
>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
>> index ed3b785..8b3fdb1 100644
>> --- a/drivers/dma-buf/Kconfig
>> +++ b/drivers/dma-buf/Kconfig
>> @@ -30,4 +30,13 @@ config SW_SYNC
>>WARNING: improper use of this can result in deadlocking kernel
>>drivers from userspace. Intended for test and debug only.
>>  
>> +config DMA_BUF_TEST
>> +bool "Test module for dma-buf"
>> +default n
>> +---help---
>> +  A test module to validate dma_buf APIs. This should not be
>> +  enabled for general use.
>> +
>> +  Say N here unless you know you want this.
>> +
>>  endmenu
>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>> index c33bf88..5029608 100644
>> --- a/drivers/dma-buf/Makefile
>> +++ b/drivers/dma-buf/Makefile
>> @@ -1,3 +1,4 @@
>>  obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>>  obj-$(CONFIG_SYNC_FILE) += sync_file.o
>>  obj-$(CONFIG_SW_SYNC)   += sw_sync.o sync_debug.o
>> +obj-$(CONFIG_DMA_BUF_TEST)  += dma-buf-test.o
>> diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
>> new file mode 100644
>> index 000..3af131c
>> --- /dev/null
>> +++ b/drivers/dma-buf/dma-buf-test.c
>> @@ -0,0 +1,309 @@
>> +/*
>> + * Copyright (C) 2013 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License versdma_buf 2, as published by the Free Software Foundatdma_buf, 
>> 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.
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "dma-buf-test: " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +struct dma_buf_test_device {
>> +struct miscdevice misc;
>> +};
>> +
>> +struct dma_buf_test_data {
>> +struct dma_buf *dma_buf;
>> +struct device *dev;
>> +};
>> +
>> +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf 
>> *dma_buf,
>> +   void __user *ptr, size_t offset, size_t size,
>> +   bool write)
>> +{
>> +int ret = 0;
>> +struct dma_buf_attachment *attach;
>> +struct sg_table *table;
>> +pgprot_t pgprot = pgpr

[RFC][PATCH] dma-buf: Introduce dma-buf test module

2017-03-14 Thread Laura Abbott

dma-buf is designed to share buffers. Sharing means that there needs to
be another subsystem to accept those buffers. Introduce a simple test
module to act as a dummy system to accept dma_bufs from elsewhere. The
goal is to provide a very simple interface to validate exported buffers
do something reasonable. This is based on ion_test.c that existed for
the Ion framework.

Signed-off-by: Laura Abbott <labb...@redhat.com>
---
This is basically a drop in of what was available as
drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
parts it might be useful as a more general test module. RFC mostly
to see if this is generally useful or not.
---
 drivers/dma-buf/Kconfig   |   9 ++
 drivers/dma-buf/Makefile  |   1 +
 drivers/dma-buf/dma-buf-test.c| 309 ++
 include/uapi/linux/dma_buf_test.h |  67 +
 4 files changed, 386 insertions(+)
 create mode 100644 drivers/dma-buf/dma-buf-test.c
 create mode 100644 include/uapi/linux/dma_buf_test.h

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ed3b785..8b3fdb1 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -30,4 +30,13 @@ config SW_SYNC
  WARNING: improper use of this can result in deadlocking kernel
  drivers from userspace. Intended for test and debug only.
 
+config DMA_BUF_TEST
+   bool "Test module for dma-buf"
+   default n
+   ---help---
+ A test module to validate dma_buf APIs. This should not be
+ enabled for general use.
+
+ Say N here unless you know you want this.
+
 endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index c33bf88..5029608 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,3 +1,4 @@
 obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
+obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o
diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
new file mode 100644
index 000..3af131c
--- /dev/null
+++ b/drivers/dma-buf/dma-buf-test.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License versdma_buf 2, as published by the Free Software Foundatdma_buf, 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.
+ *
+ */
+
+#define pr_fmt(fmt) "dma-buf-test: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dma_buf_test_device {
+   struct miscdevice misc;
+};
+
+struct dma_buf_test_data {
+   struct dma_buf *dma_buf;
+   struct device *dev;
+};
+
+static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf *dma_buf,
+  void __user *ptr, size_t offset, size_t size,
+  bool write)
+{
+   int ret = 0;
+   struct dma_buf_attachment *attach;
+   struct sg_table *table;
+   pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
+   enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+   struct sg_page_iter sg_iter;
+   unsigned long offset_page;
+
+   attach = dma_buf_attach(dma_buf, dev);
+   if (IS_ERR(attach))
+   return PTR_ERR(attach);
+
+   table = dma_buf_map_attachment(attach, dir);
+   if (IS_ERR(table))
+   return PTR_ERR(table);
+
+   offset_page = offset >> PAGE_SHIFT;
+   offset %= PAGE_SIZE;
+
+   for_each_sg_page(table->sgl, _iter, table->nents, offset_page) {
+   struct page *page = sg_page_iter_page(_iter);
+   void *vaddr = vmap(, 1, VM_MAP, pgprot);
+   size_t to_copy = PAGE_SIZE - offset;
+
+   to_copy = min(to_copy, size);
+   if (!vaddr) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   if (write)
+   ret = copy_from_user(vaddr + offset, ptr, to_copy);
+   else
+   ret = copy_to_user(ptr, vaddr + offset, to_copy);
+
+   vunmap(vaddr);
+   if (ret) {
+   ret = -EFAULT;
+   goto err;
+   }
+   size -= to_copy;
+   if (!size)
+   break;
+   ptr += to_copy;
+   offset = 0;
+   }
+
+err:
+   dma_buf_unmap_attachment(attach, table, dir);
+   dma_buf_detach(dma_buf, attach)

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

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

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

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

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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura


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

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

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

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

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

> The existing query ioctl can allow heap IDs to get assigned
> dynamically at runtime, so there's no need to reserve "bit 6" for
> "CUSTOM_ACME_HEAP_1"
> 
>> Another point is how can we put secure rules (like selinux policy) on
>> heaps since all the allocations
>> go to the same device (/dev/ion) ?

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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura



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

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

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

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

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

Yes, that was my thinking. 

> 
> Benjamin
> 

Thanks,
Laura



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

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

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


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

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

Thanks,
Laura


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

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

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

Thanks,
Laura

 



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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura


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

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

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

Thanks,
Laura



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

2017-03-03 Thread Laura Abbott
On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
> 
> Thank you for the patch.
> 
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
>> ensure this happens. As a side effect, this lets Ion buffers take
>> advantage of the dma_buf sync ioctls.
>>
>> Signed-off-by: Laura Abbott <labb...@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(>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, >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(>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
>> d

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

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

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

Thanks,
Laura



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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 000..21344c7
--- /dev/null
+++ b/drivers/staging/android/ion/ion_enumerate.c
@@ -0,0 +1,89 @@
+#include 
+#include 
+
+#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();
+   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();
+   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();
+   if (!heap)
+   return -ENODEV;
+
+   ion_device_add_heap(internal_dev, heap);
+   return 0;
+}
+#endif
+
+
+static int ion_add_cma_heaps(void)
+{
+#ifdef CONFIG_ION_CMA_HEAP
+   cma_for_each_area(__ion_add_cma_heaps, NULL);
+#endif
+   return 0;
+}
+
+int ion_enumerate(void)
+{
+   internal_dev = ion_device_create(NULL);
+   if (IS_ERR(internal_dev))
+   return PTR_ERR(internal_dev);
+
+   ion_add_system_heap();
+   ion_add_system_contig_heap();
+
+   ion_add_cma_heaps();
+   return 0;
+}
+subsys_initcall(ion_enumerate);
-- 
2.7.4



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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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(>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 - allocat

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

2017-03-02 Thread Laura Abbott
Hi,

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

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

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

Feedback appreciated.

Thanks,
Laura

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

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

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

-- 
2.7.4



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

2017-03-02 Thread Laura Abbott


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

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

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



[RFC PATCH 09/12] cma: Introduce cma_for_each_area

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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(_areas[i], data);
+
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
-- 
2.7.4



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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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, );
+   err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name, 
);
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
@@ -16

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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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) { }
+

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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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 
 #include 
 #include 
-#include 
+#include 
+#include 
 
 #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,
-stru

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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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..000
--- 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..000
--- 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..000
--- 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.c...@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 
-#include 
-#include 
-#include 
-#include 
-#include "../ion_priv.h

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

2017-03-02 Thread Laura Abbott

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

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

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



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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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(>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, >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(>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(>lock);
+   vaddr = ion_buffer_kmap_get(buffer);
+   mutex_unlock(>lock);
}
 
-   mutex_lock(>lock);
-   vaddr = ion_buffer_kmap_get(buffer);
-   mutex_unlock(>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,
+  

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

2017-03-02 Thread Laura Abbott

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

Signed-off-by: Laura Abbott <labb...@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(>vmas);
@@ -876,69 +831,6 @@ void ion_pages_sync_for_device(struct device *dev, struct 
page *page,
dma_sync_sg_for_device(dev, , 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(>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(>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(>lock);
-   list_add(_list->list, >vmas);
-   mutex_unlock(>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(>lock);
-   list_for_each_entry_safe(vma_list, tmp, >vmas, list) {
-   if (vma_list->vma != vma)
-   continue;
-   list_del(_list->list);
-   kfree(vma_list);
-   pr_debug("%s: deleting %p\n", __func__, vma);
-   break;
-   }
-   mutex_unlock(>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)) {
-   

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

2017-03-02 Thread Laura Abbott


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

Signed-off-by: Laura Abbott <labb...@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(, 1);
-   sg_set_page(, 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() = page_to_phys(page);
-   dma_sync_sg_for_device(dev, , 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 != _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, 

Re: [RFC simple allocator v2 0/2] Simple allocator

2017-02-13 Thread Laura Abbott
On 02/13/2017 10:18 AM, Mark Brown wrote:
> On Mon, Feb 13, 2017 at 03:45:04PM +0100, Benjamin Gaignard wrote:
> 
>> An other question is: do we have others memory regions that could be 
>> interested
>> by this new framework ? I have in mind that some title memory regions could 
>> use
>> it or replace ION heaps (system, carveout, etc...).
>> Maybe it only solve CMA allocation issue, in this case there is no need to 
>> create
>> a new framework but only a dedicated ioctl.
> 
> The software defined networking people seemed to think they had a use
> case for this as well.  They're not entirely upstream of course but
> still...
> 

This is the first I've heard of anything like this. Do you have any more
details/reading?

Thanks,
Laura


Re: [RFC simple allocator v1 0/2] Simple allocator

2017-01-25 Thread Laura Abbott

On 01/23/2017 09:35 AM, Daniel Vetter wrote:

On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:

The goal of this RFC is to understand if a common ioctl for specific memory
regions allocations is needed/welcome.

Obviously it will not replace allocation done in linux kernel frameworks like
v4l2, drm/kms or others, but offer an alternative when you don't want/need to
use them for buffer allocation.
To keep a compatibility with what already exist allocated buffers are exported
in userland as dmabuf file descriptor (like ION is doing).

"Unix Device Memory Allocator" project [1] wants to create a userland library
which may allow to select, depending of the devices constraint, the best
back-end for allocation. With this RFC I would to propose to have common ioctl
for a maximum of allocators to avoid to duplicated back-ends for this library.

One of the issues that lead me to propose this RFC it is that since the 
beginning
it is a problem to allocate contiguous memory (CMA) without using v4l2 or
drm/kms so the first allocator available in this RFC use CMA memory.

An other question is: do we have others memory regions that could be interested
by this new framework ? I have in mind that some title memory regions could use
it or replace ION heaps (system, carveout, etc...).
Maybe it only solve CMA allocation issue, in this case there is no need to 
create
a new framework but only a dedicated ioctl.

Maybe the first thing to do is to change the name and the location of this
module, suggestions are welcome.

I have testing this code with the following program:


I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel



(I thought I sent this before but apparently it didn't go through.
Apologies if this ends up as a repeat for anyone)

I've been reviewing this as well. Even if Ion is used on a number of
devices, the model is still a bit clunky. I was hoping to see if it
could be re-written from scratch in a framework like this and then
either add a shim layer or just coax all devices out there to actually
convert to the new framework.

I supposed another option is to destage as you suggested and work on
an improved version in parallel.

Thanks,
Laura


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2016-12-14 Thread Laura Abbott

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

Not-signed-off-by: Laura Abbott <labb...@redhat.com>
---
 drivers/staging/android/ion/ion.c | 61 ++-
 1 file changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 86dba07..5177d79 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -776,6 +776,11 @@ 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)
@@ -784,15 +789,29 @@ static struct sg_table *ion_map_dma_buf(struct 
dma_buf_attachment *attachment,
struct ion_buffer *buffer = dmabuf->priv;
struct sg_table *table;
 
-   return dup_sg_table(buffer->sg_table);
+   /*
+* TODO: Need to sync wrt CPU or device completely owning?
+*/
+
+   table = 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);
 }
 
 struct ion_vma_list {
@@ -889,16 +908,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(>lock);
+   vaddr = ion_buffer_kmap_get(buffer);
+   mutex_unlock(>lock);
}
 
-   mutex_lock(>lock);
-   vaddr = ion_buffer_kmap_get(buffer);
-   mutex_unlock(>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,
@@ -906,9 +933,15 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf 
*dmabuf,
 {
struct ion_buffer *buffer = dmabuf->priv;
 
-   mutex_lock(>lock);
-   ion_buffer_kmap_put(buffer);
-   mutex_unlock(>lock);
+   if (buffer->heap->ops->map_kernel) {
+   mutex_lock(>lock);
+   ion_buffer_kmap_put(buffer);
+   mutex_unlock(>lock);
+   }
+
+   dma_unmap_sg(buffer->dev->dev.this_device, buffer->sg_table->sgl,
+   buffer->sg_table->nents,
+   DMA_BIDIRECTIONAL);
 
return 0;
 }
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


  1   2   >