[Linaro-mm-sig] [PATCH 1/3] make struct ion_device available for other heap
Benjamin Gaignard
benjamin.gaignard at linaro.org
Wed Mar 14 12:46:35 UTC 2012
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 at 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 at 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 at 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 at 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 at 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 at stericsson.com>
>> >> > wrote:
>> >> >>
>> >> >> From: Benjamin Gaignard <benjamin.gaignard at 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 at 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 at lists.linaro.org
>> >> >> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Linaro-mm-sig mailing list
>> >> > Linaro-mm-sig at lists.linaro.org
>> >> > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>> >> >
>> >
>> >
>>
>
> _______________________________________________
> Linaro-mm-sig mailing list
> Linaro-mm-sig at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
>
>
--
Benjamin Gaignard
Multimedia Working Group
Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs
**
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
Twitter<http://twitter.com/#!/linaroorg>
| Blog <http://www.linaro.org/linaro-blog/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20120314/02f58ceb/attachment.html>
More information about the Linaro-mm-sig
mailing list