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