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.
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
>