From: benjamin gaignard benjamin.gaignard@linaro.org
The goal of those patches is to allow ION clients (drivers or userland applications) to use Contiguous Memory Allocator (CMA).
To get more info about CMA: http://lists.linaro.org/pipermail/linaro-mm-sig/2012-February/001328.html
patches version 2: fix comments done by Andy Green
Benjamin Gaignard (3): make struct ion_device available for other heap fix ion_platform_data definition add CMA heap
drivers/gpu/ion/Kconfig | 5 + drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/cma/Makefile | 1 + drivers/gpu/ion/cma/ion_cma_heap.c | 217 ++++++++++++++++++++++++++++++++++++ drivers/gpu/ion/ion.c | 20 ---- drivers/gpu/ion/ion_priv.h | 22 ++++ include/linux/ion.h | 2 +- 7 files changed, 247 insertions(+), 21 deletions(-) create mode 100644 drivers/gpu/ion/cma/Makefile create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.c
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
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
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
For CMA, you are using (for ex), dma_alloc_coherent().. so pool wouldn't need to poke into other data, but would need the 'struct device *'
possibly the device ptr could be stuffed in 'struct ion_heap' or somewhere else?
BR, -R
On Tue, Mar 13, 2012 at 12:13 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
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
What do you think about a "priv" field in ion_platform_heap instead? My concern is the ion_device is global to all of ion but the data you are trying to get to is really heap specific. What if you wanted two different contiguous heaps? There'd be no way to plumb that through ion.
Rebecca
On Tue, Mar 13, 2012 at 12:44 PM, Clark, Rob rob@ti.com wrote:
For CMA, you are using (for ex), dma_alloc_coherent().. so pool wouldn't need to poke into other data, but would need the 'struct device *'
possibly the device ptr could be stuffed in 'struct ion_heap' or somewhere else?
BR, -R
On Tue, Mar 13, 2012 at 12:13 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
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 intcmd,
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 intcmd,
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
I guess if you made 'ion_platform_heap' it's own device.. not really sure if that is overkill, going down that path (ion_device, ion_bus, etc ;-)).
BR, -R
On Tue, Mar 13, 2012 at 3:59 PM, Rebecca Schultz Zavin rschultz@google.com wrote:
What do you think about a "priv" field in ion_platform_heap instead? My concern is the ion_device is global to all of ion but the data you are trying to get to is really heap specific. What if you wanted two different contiguous heaps? There'd be no way to plumb that through ion.
Rebecca
On Tue, Mar 13, 2012 at 12:44 PM, Clark, Rob rob@ti.com wrote:
For CMA, you are using (for ex), dma_alloc_coherent().. so pool wouldn't need to poke into other data, but would need the 'struct device *'
possibly the device ptr could be stuffed in 'struct ion_heap' or somewhere else?
BR, -R
On Tue, Mar 13, 2012 at 12:13 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
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
I guess we'd need a priv field in both ion_platform_heap and ion_heap. Then create a platform device in your board file and pass that dev node in the ion_platform_heap structure. When you create your heaps you can stuff that priv field into the heap itself and access it again later when you alloc/free etc. I like that better than digging around for the dev that you happen to know you created as the parent etc etc. What do you think?
Rebecca
On Mar 13, 2012 2:41 PM, "Clark, Rob" rob@ti.com wrote:
I guess if you made 'ion_platform_heap' it's own device.. not really sure if that is overkill, going down that path (ion_device, ion_bus, etc ;-)).
BR, -R
On Tue, Mar 13, 2012 at 3:59 PM, Rebecca Schultz Zavin rschultz@google.com wrote:
What do you think about a "priv" field in ion_platform_heap instead? My concern is the ion_device is global to all of ion but the data you are trying to get to is really heap specific. What if you wanted two different contiguous heaps? There'd be no way to plumb that through ion.
Rebecca
On Tue, Mar 13, 2012 at 12:44 PM, Clark, Rob rob@ti.com wrote:
For CMA, you are using (for ex), dma_alloc_coherent().. so pool wouldn't need to poke into other data, but would need the 'struct device *'
possibly the device ptr could be stuffed in 'struct ion_heap' or
somewhere
else?
BR, -R
On Tue, Mar 13, 2012 at 12:13 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
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 intcmd,
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 intcmd,
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
I think it possible to add a private field in ion_heap to store teh dev needed by dma API. I will work on that idea and send a new version of the patches.
Benjamin
2012/3/14 Rebecca Schultz Zavin rschultz@google.com
I guess we'd need a priv field in both ion_platform_heap and ion_heap. Then create a platform device in your board file and pass that dev node in the ion_platform_heap structure. When you create your heaps you can stuff that priv field into the heap itself and access it again later when you alloc/free etc. I like that better than digging around for the dev that you happen to know you created as the parent etc etc. What do you think?
Rebecca
On Mar 13, 2012 2:41 PM, "Clark, Rob" rob@ti.com wrote:
I guess if you made 'ion_platform_heap' it's own device.. not really sure if that is overkill, going down that path (ion_device, ion_bus, etc ;-)).
BR, -R
On Tue, Mar 13, 2012 at 3:59 PM, Rebecca Schultz Zavin rschultz@google.com wrote:
What do you think about a "priv" field in ion_platform_heap instead? My concern is the ion_device is global to all of ion but the data you are trying to get to is really heap specific. What if you wanted two different contiguous heaps? There'd be no way to plumb that through ion.
Rebecca
On Tue, Mar 13, 2012 at 12:44 PM, Clark, Rob rob@ti.com wrote:
For CMA, you are using (for ex), dma_alloc_coherent().. so pool wouldn't need to poke into other data, but would need the 'struct device *'
possibly the device ptr could be stuffed in 'struct ion_heap' or
somewhere
else?
BR, -R
On Tue, Mar 13, 2012 at 12:13 PM, Rebecca Schultz Zavin rebecca@android.com wrote:
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, unsignedint
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, unsignedint
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
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
From: Benjamin Gaignard benjamin.gaignard@linaro.org
fix ion_platform_heap to make is use an usual way in board configuration file.
Signed-off-by: Benjamin Gaignard benjamin.gaignard@linaro.org --- include/linux/ion.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/ion.h b/include/linux/ion.h index aed8349..1468cb3 100644 --- a/include/linux/ion.h +++ b/include/linux/ion.h @@ -83,7 +83,7 @@ struct ion_platform_heap { */ struct ion_platform_data { int nr; - struct ion_platform_heap heaps[]; + struct ion_platform_heap *heaps; };
/**
On Tue, Mar 13, 2012 at 7:09 AM, benjamin.gaignard@stericsson.com wrote:
From: Benjamin Gaignard benjamin.gaignard@linaro.org
fix ion_platform_heap to make is use an usual way in board configuration file.
Signed-off-by: Benjamin Gaignard benjamin.gaignard@linaro.org
include/linux/ion.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/ion.h b/include/linux/ion.h index aed8349..1468cb3 100644 --- a/include/linux/ion.h +++ b/include/linux/ion.h @@ -83,7 +83,7 @@ struct ion_platform_heap { */ struct ion_platform_data { int nr;
struct ion_platform_heap heaps[];
struct ion_platform_heap *heaps;};
/**
Can you give me some context on why you need this change?
-- 1.7.0.4
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
it is to use ion_platform_heap like this in board configuration file.
It is only an example for test purpose do not merge it It create 2 heaps (#1 and #2) where we can allocate/mmap/free buffers from userland application
Signed-off-by: Benjamin Gaignard benjamin.gaignard@linaro.org --- arch/arm/mach-ux500/board-mop500.c | 60 ++++++++++++++++++++++++++++++ ++++++ 1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board- mop500.c index bdd7b80..b0242f5 100644 --- a/arch/arm/mach-ux500/board-mop500.c +++ b/arch/arm/mach-ux500/board-mop500.c @@ -50,6 +50,45 @@ #include "board-mop500.h" #include "board-mop500-regulators.h"
+#ifdef CONFIG_ION +#include <linux/ion.h> +#include <linux/dma-contiguous.h> +#endif + +#ifdef CONFIG_ION_CMA + +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), + }, + [1] = { + .type = ION_HEAP_TYPE_SYSTEM_CONTIG, + .id = 2, + .name = "ion-cma-heap-2", + .base = 0, + .size = (16 * SZ_1M), + }, +}; + +static struct ion_platform_data snowball_ion_data = { + .heaps = snowball_ion_heaps, + .nr = ARRAY_SIZE(snowball_ion_heaps), +}; + +static struct platform_device snowball_ion_device = { + .name = "ion-cma", + .id = -1, + .dev = { + .platform_data = &snowball_ion_data, + }, + .num_resources = 0, +}; +#endif + static struct gpio_led snowball_led_array[] = { { .name = "user_led", @@ -598,8 +637,26 @@ static struct platform_device *snowball_platform_devs[] __initdata = { &snowball_key_dev, &snowball_sbnet_dev, &ab8500_device, +#ifdef CONFIG_ION_CMA + &snowball_ion_device, +#endif };
+#ifdef CONFIG_ION_CMA +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__); +} +#endif + static void __init mop500_init_machine(void) { int i2c0_devs; @@ -713,4 +770,7 @@ MACHINE_START(SNOWBALL, "Calao Systems Snowball platform") /* we re-use nomadik timer here */ .timer = &ux500_timer, .init_machine = snowball_init_machine, +#ifdef CONFIG_ION_CMA + .reserve = mop500_reserve, +#endif MACHINE_END
2012/3/13 Rebecca Schultz Zavin rschultz@google.com
On Tue, Mar 13, 2012 at 7:09 AM, benjamin.gaignard@stericsson.com wrote:
From: Benjamin Gaignard benjamin.gaignard@linaro.org
fix ion_platform_heap to make is use an usual way in board configuration file.
Signed-off-by: Benjamin Gaignard benjamin.gaignard@linaro.org
include/linux/ion.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/ion.h b/include/linux/ion.h index aed8349..1468cb3 100644 --- a/include/linux/ion.h +++ b/include/linux/ion.h @@ -83,7 +83,7 @@ struct ion_platform_heap { */ struct ion_platform_data { int nr;
struct ion_platform_heap heaps[];
struct ion_platform_heap *heaps;};
/**
Can you give me some context on why you need this change?
-- 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
From: benjamin gaignard benjamin.gaignard@linaro.org
New heap, allocation is done with dma_alloc_coherent API. device coherent_dma_mask is set to DMA_BIT_MASK(32) Heap type isn't checked but we can think that ION_HEAP_TYPE_SYSTEM_CONTIG is the correct choice
Signed-off-by: Benjamin Gaignard benjamin.gaignard@linaro.org --- drivers/gpu/ion/Kconfig | 5 + drivers/gpu/ion/Makefile | 1 + drivers/gpu/ion/cma/Makefile | 1 + drivers/gpu/ion/cma/ion_cma_heap.c | 217 ++++++++++++++++++++++++++++++++++++ 4 files changed, 224 insertions(+), 0 deletions(-) create mode 100644 drivers/gpu/ion/cma/Makefile create mode 100644 drivers/gpu/ion/cma/ion_cma_heap.c
diff --git a/drivers/gpu/ion/Kconfig b/drivers/gpu/ion/Kconfig index 5b48b4e..231dbb1 100644 --- a/drivers/gpu/ion/Kconfig +++ b/drivers/gpu/ion/Kconfig @@ -10,3 +10,8 @@ config ION_TEGRA help Choose this option if you wish to use ion on an nVidia Tegra.
+config ION_CMA + tristate "Ion CMA heap" + depends on ION && CMA + help + Choose this option to enable ION CMA heap. diff --git a/drivers/gpu/ion/Makefile b/drivers/gpu/ion/Makefile index 73fe3fa..05f174a 100644 --- a/drivers/gpu/ion/Makefile +++ b/drivers/gpu/ion/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_ION) += ion.o ion_heap.o ion_system_heap.o ion_carveout_heap.o obj-$(CONFIG_ION_TEGRA) += tegra/ +obj-$(CONFIG_ION_CMA) += cma/ diff --git a/drivers/gpu/ion/cma/Makefile b/drivers/gpu/ion/cma/Makefile new file mode 100644 index 0000000..673508d --- /dev/null +++ b/drivers/gpu/ion/cma/Makefile @@ -0,0 +1 @@ +obj-y += ion_cma_heap.o diff --git a/drivers/gpu/ion/cma/ion_cma_heap.c b/drivers/gpu/ion/cma/ion_cma_heap.c new file mode 100644 index 0000000..1714316 --- /dev/null +++ b/drivers/gpu/ion/cma/ion_cma_heap.c @@ -0,0 +1,217 @@ +/* + * drivers/gpu/ion/ion_cma_heap.c + * + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include <linux/device.h> +#include <linux/ion.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/errno.h> +#include <linux/err.h> +#include <linux/miscdevice.h> +#include <linux/dma-mapping.h> + +/* for ion_heap_ops structure */ +#include "../ion_priv.h" + +#define ION_CMA_ALLOCATE_FAILED -1 + +static u64 dma_mask = DMA_BIT_MASK(32); + +struct ion_heap **heaps; +struct ion_device *ion_cma_device; + +struct ion_cma_buffer_info { + void *cpu_addr; + dma_addr_t handle; +}; + +/* ION CMA heap operations functions */ +static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer, + unsigned long len, unsigned long align, + unsigned long 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; +} + +static void ion_cma_free(struct ion_buffer *buffer) +{ + struct ion_device *idev = buffer->dev; + struct device *dev = idev->dev.parent; + struct ion_cma_buffer_info *info = buffer->priv_virt; + + dev_dbg(dev, "Release buffer %p\n", buffer); + dma_free_coherent(dev, buffer->size, info->cpu_addr, info->handle); + kfree(info); +} + +/* return physical address in addr */ +static int ion_cma_phys(struct ion_heap *heap, struct ion_buffer *buffer, + ion_phys_addr_t *addr, size_t *len) +{ + struct ion_device *idev = buffer->dev; + struct device *dev = idev->dev.parent; + struct ion_cma_buffer_info *info = buffer->priv_virt; + + dev_dbg(dev, "Return buffer %p physical address 0x%x\n", buffer, + virt_to_phys(info->cpu_addr)); + + *addr = virt_to_phys(info->cpu_addr); + *len = buffer->size; + + return 0; +} + +static int ion_cma_mmap(struct ion_heap *mapper, struct ion_buffer *buffer, + struct vm_area_struct *vma) +{ + struct ion_device *idev = buffer->dev; + struct device *dev = idev->dev.parent; + struct ion_cma_buffer_info *info = buffer->priv_virt; + + return dma_mmap_coherent(dev, vma, info->cpu_addr, info->handle, + buffer->size); +} + +static struct ion_heap_ops ion_cma_ops = { + .allocate = ion_cma_allocate, + .free = ion_cma_free, + .phys = ion_cma_phys, + .map_user = ion_cma_mmap, +}; + +struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data) +{ + struct ion_heap *heap; + + heap = ion_heap_create(data); + + if (heap) + heap->ops = &ion_cma_ops; + + return heap; +} + +/* ION CMA heap platform driver functions */ +int ion_cma_probe(struct platform_device *pdev) +{ + struct ion_platform_data *pdata = pdev->dev.platform_data; + int num_heaps = pdata->nr; + int i, err; + + heaps = kzalloc(sizeof(struct ion_heap *) * num_heaps, GFP_KERNEL); + + dev_info(&pdev->dev, "Create ION CMA device %p\n", &pdev->dev); + ion_cma_device = ion_device_create(NULL); + if (IS_ERR_OR_NULL(ion_cma_device)) { + kfree(heaps); + dev_err(&pdev->dev, "Can't create ION CMA device\n"); + return PTR_ERR(ion_cma_device); + } + + ion_cma_device->dev.parent = &pdev->dev; + + /* set dma mask for this device */ + pdev->dev.dma_mask = &dma_mask; + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + + /* create all the heaps specified in board configuration file */ + for (i = 0; i < num_heaps; i++) { + struct ion_platform_heap *heap_data = &pdata->heaps[i]; + + heaps[i] = ion_cma_heap_create(heap_data); + if (IS_ERR_OR_NULL(heaps[i])) { + dev_err(&pdev->dev, "Can't create heap %s\n", + heap_data->name); + err = PTR_ERR(heaps[i]); + goto err; + } + ion_device_add_heap(ion_cma_device, heaps[i]); + dev_dbg(&pdev->dev, "Add heap %s\n", heap_data->name); + } + + platform_set_drvdata(pdev, ion_cma_device); + return 0; + +err: + for (i = 0; i < num_heaps; i++) + if (heaps[i]) + ion_heap_destroy(heaps[i]); + + kfree(heaps); + return err; +} + +int ion_cma_remove(struct platform_device *pdev) +{ + struct ion_device *idev = platform_get_drvdata(pdev); + struct ion_platform_data *pdata = pdev->dev.platform_data; + int i, num_heaps; + + num_heaps = pdata->nr; + + /* remove ION device */ + ion_device_destroy(idev); + + /* remove all heaps create by the driver */ + for (i = 0; i < num_heaps; i++) + if (heaps[i]) + ion_heap_destroy(heaps[i]); + + return 0; +} + +static struct platform_driver ion_cma_driver = { + .probe = ion_cma_probe, + .remove = ion_cma_remove, + .driver = { + .name = "ion-cma" + } +}; + +static int __init ion_cma_init(void) +{ + return platform_driver_register(&ion_cma_driver); +} + +static void __exit ion_cma_exit(void) +{ + platform_driver_unregister(&ion_cma_driver); +} + +module_init(ion_cma_init); +module_exit(ion_cma_exit);
linaro-mm-sig@lists.linaro.org
-
Benjamin Gaignard -
benjamin.gaignard＠stericsson.com -
Clark, Rob -
Rebecca Schultz Zavin -
Rebecca Schultz Zavin