[Linaro-mm-sig] [PATCH 1/3] make struct ion_device available for other heap
Rebecca Schultz Zavin
rschultz at google.com
Wed Mar 14 00:10:52 UTC 2012
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
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/linaro-mm-sig/attachments/20120313/60ea3550/attachment.html>
More information about the Linaro-mm-sig
mailing list