[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141011184030.GG26941@phenom.ffwll.local>
Date: Sat, 11 Oct 2014 20:40:30 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Sumit Semwal <sumit.semwal@...aro.org>,
linaro-mm-sig@...ts.linaro.org, linaro-kernel@...ts.linaro.org,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-media@...r.kernel.org
Subject: Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for
dma-buf
On Fri, Oct 10, 2014 at 04:09:00PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote:
> > Devices sharing buffers using dma-buf could benefit from sharing their
> > constraints via struct device, and dma-buf framework would manage the
> > common constraints for all attached devices per buffer.
> >
> > With that information, we could have a 'generic' allocator helper in
> > the form of a central dma-buf exporter, which can create dma-bufs, and
> > allocate backing storage at the time of first call to
> > dma_buf_map_attachment.
> >
> > This allocation would utilise the constraint-mask by matching it to
> > the right allocator from a pool of allocators, and then allocating
> > buffer backing storage from this allocator.
> >
> > The pool of allocators could be platform-dependent, allowing for
> > platforms to hide the specifics of these allocators from the devices
> > that access the dma-buf buffers.
> >
> > A sample sequence could be:
> > - get handle to cenalloc_device,
> > - create a dmabuf using cenalloc_buffer_create;
> > - use this dmabuf to attach each device, which has its constraints
> > set in the constraints mask (dev->dma_params->access_constraints_mask)
> > - at each dma_buf_attach() call, dma-buf will check to see if the constraint
> > mask for the device requesting attachment is compatible with the constraints
> > of devices already attached to the dma-buf; returns an error if it isn't.
> > - after all devices have attached, the first call to dma_buf_map_attachment()
> > will allocate the backing storage for the buffer.
> > - follow the dma-buf api for map / unmap etc usage.
> > - detach all attachments,
> > - call cenalloc_buffer_free to free the buffer if refcount reaches zero;
> >
> > ** IMPORTANT**
> > This mechanism of delayed allocation based on constraint-enablement will work
> > *ONLY IF* the first map_attachment() call is made AFTER all attach() calls are
> > done.
> >
> > Signed-off-by: Sumit Semwal <sumit.semwal@...aro.org>
> > Cc: linux-kernel@...r.kernel.org
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: linux-media@...r.kernel.org
> > Cc: dri-devel@...ts.freedesktop.org
> > Cc: linaro-mm-sig@...ts.linaro.org
> > ---
> > MAINTAINERS | 1 +
> > drivers/cenalloc/cenalloc.c | 597 +++++++++++++++++++++++++++++++++++++++
> > drivers/cenalloc/cenalloc.h | 99 +++++++
> > drivers/cenalloc/cenalloc_priv.h | 188 ++++++++++++
> > 4 files changed, 885 insertions(+)
> > create mode 100644 drivers/cenalloc/cenalloc.c
> > create mode 100644 drivers/cenalloc/cenalloc.h
> > create mode 100644 drivers/cenalloc/cenalloc_priv.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 40d4796..e88ac81 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3039,6 +3039,7 @@ L: linux-media@...r.kernel.org
> > L: dri-devel@...ts.freedesktop.org
> > L: linaro-mm-sig@...ts.linaro.org
> > F: drivers/dma-buf/
> > +F: drivers/cenalloc/
> > F: include/linux/dma-buf*
> > F: include/linux/reservation.h
> > F: include/linux/*fence.h
> > diff --git a/drivers/cenalloc/cenalloc.c b/drivers/cenalloc/cenalloc.c
> > new file mode 100644
> > index 0000000..f278056
> > --- /dev/null
> > +++ b/drivers/cenalloc/cenalloc.c
> > @@ -0,0 +1,597 @@
> > +/*
> > + * Allocator helper framework for constraints-aware dma-buf backing storage
> > + * allocation.
> > + * This allows constraint-sharing devices to deferred-allocate buffers shared
> > + * via dma-buf.
> > + *
> > + * Copyright(C) 2014 Linaro Limited. All rights reserved.
> > + * Author: Sumit Semwal <sumit.semwal@...aro.org>
> > + *
> > + * Structure for management of clients, buffers etc heavily derived from
> > + * Android's ION framework.
>
> Does that mean we can drop ION after this gets merged?
Yeah, I hope so. Not sure whetether this hope is shared by google android
people ...
> /me dreams
I guess we can collectively dream about this next week at plumbers ;-)
I'll try to squeeze in some light review of Sumit's patches between
conference travels ...
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists