CMA heap need to know the misc device to make the link between the memory region declared as contiguous in board configuration file and the call of dma_alloc_coherent in CMA heap.

If not CMA memory region has associated with the device, dma_alloc_coherent will allocate buffer in the default CMA region. 

In configuration file we have heaps definitions and dma contiguous memory declaration

+struct ion_platform_heap snowball_ion_heaps[] = {
+       [0] = {
+               .type = ION_HEAP_TYPE_SYSTEM_CONTIG,
+               .id = 1,
+               .name = "ion-cma-heap-1",
+               .base = 0,
+               .size = (16 * SZ_1M),
+       },
+}; 

+static void __init mop500_reserve(void)
+{
+       int err;
+       struct ion_platform_data *data = snowball_ion_device.dev.platform_data;
+
+       err = dma_declare_contiguous(&snowball_ion_device.dev,
+                               data->heaps[0].size, data->heaps[0].base, 0);
+       if (err)
+               printk(KERN_ERR "ION CMA: can't declare dma contiguous\n");
+       else
+               printk(KERN_INFO "%s: reserve OK\n", __func__);
+} 

and in CMA heap we use the device to allocate buffer in the selected memory region

+static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
+                    unsigned long len, unsigned long align,
+                    unsigned long flags)
+{
+       struct ion_device *idev = heap->dev;
+       struct device *dev = idev->dev.parent;
+       struct ion_cma_buffer_info *info;
+
+       dev_dbg(dev, "Request buffer allocation len %ld\n", len);
+
+       info = kzalloc(sizeof(struct ion_cma_buffer_info), GFP_KERNEL);
+       if (!info) {
+               dev_err(dev, "Can't allocate buffer info\n");
+               return ION_CMA_ALLOCATE_FAILED;
+       }
+
+       info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle), 0);
+
+       if (!info->cpu_addr) {
+               dev_err(dev, "Fail to allocate buffer\n");
+               kfree(info);
+               return ION_CMA_ALLOCATE_FAILED;
+       }
+
+       /* keep this for memory release */
+       buffer->priv_virt = info;
+       dev_dbg(dev, "Allocate buffer %p\n", buffer);
+       return 0;
+} 


2012/3/13 Rebecca Schultz Zavin <rebecca@android.com>
It's not clear to me why you need to make this change.  The ion_device is intentionally not defined in the header so heap implementers won't be tempted to mess with any data in there.  Maybe if you share the snippet of code where you use this in your board file with me it'll make more sense.  

Thanks,
Rebecca

On Tue, Mar 13, 2012 at 7:09 AM, <benjamin.gaignard@stericsson.com> wrote:
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>

CMA heap needs to know misc device to be able to do the link between
ION heap and CMA area reserved in board configuration file.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
 drivers/gpu/ion/ion.c      |   20 --------------------
 drivers/gpu/ion/ion_priv.h |   22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c
index 37b23af..dbfdd7e 100644
--- a/drivers/gpu/ion/ion.c
+++ b/drivers/gpu/ion/ion.c
@@ -34,26 +34,6 @@
 #define DEBUG

 /**
- * struct ion_device - the metadata of the ion device node
- * @dev:               the actual misc device
- * @buffers:   an rb tree of all the existing buffers
- * @lock:              lock protecting the buffers & heaps trees
- * @heaps:             list of all the heaps in the system
- * @user_clients:      list of all the clients created from userspace
- */
-struct ion_device {
-       struct miscdevice dev;
-       struct rb_root buffers;
-       struct mutex lock;
-       struct rb_root heaps;
-       long (*custom_ioctl) (struct ion_client *client, unsigned int cmd,
-                             unsigned long arg);
-       struct rb_root user_clients;
-       struct rb_root kernel_clients;
-       struct dentry *debug_root;
-};
-
-/**
 * struct ion_client - a process/hw block local address space
 * @ref:               for reference counting the client
 * @node:              node in the tree of all clients
diff --git a/drivers/gpu/ion/ion_priv.h b/drivers/gpu/ion/ion_priv.h
index 3323954..82e44ea 100644
--- a/drivers/gpu/ion/ion_priv.h
+++ b/drivers/gpu/ion/ion_priv.h
@@ -22,6 +22,8 @@
 #include <linux/mutex.h>
 #include <linux/rbtree.h>
 #include <linux/ion.h>
+#include <linux/miscdevice.h>
+#include <linux/rbtree.h>

 struct ion_mapping;

@@ -38,6 +40,26 @@ struct ion_kernel_mapping {
 struct ion_buffer *ion_handle_buffer(struct ion_handle *handle);

 /**
+ * struct ion_device - the metadata of the ion device node
+ * @dev:               the actual misc device
+ * @buffers:   an rb tree of all the existing buffers
+ * @lock:              lock protecting the buffers & heaps trees
+ * @heaps:             list of all the heaps in the system
+ * @user_clients:      list of all the clients created from userspace
+ */
+struct ion_device {
+       struct miscdevice dev;
+       struct rb_root buffers;
+       struct mutex lock;
+       struct rb_root heaps;
+       long (*custom_ioctl) (struct ion_client *client, unsigned int cmd,
+                             unsigned long arg);
+       struct rb_root user_clients;
+       struct rb_root kernel_clients;
+       struct dentry *debug_root;
+};
+
+/**
 * struct ion_buffer - metadata for a particular buffer
 * @ref:               refernce count
 * @node:              node in the ion_device buffers tree
--
1.7.0.4


_______________________________________________
Linaro-mm-sig mailing list
Linaro-mm-sig@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig


_______________________________________________
Linaro-mm-sig mailing list
Linaro-mm-sig@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-mm-sig




--

Benjamin Gaignard 

Multimedia Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog