[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