Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf

[Sumit Semwal]

Hi Greg, Daniel!

On 12 October 2014 00:10, Daniel Vetter <daniel@xxxxxxxx> wrote:
> 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@xxxxxxxxxx>
>> > Cc: linux-kernel@xxxxxxxxxxxxxxx
>> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
>> > Cc: linux-media@xxxxxxxxxxxxxxx
>> > Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
>> > Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx
>> > ---
>> >  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@xxxxxxxxxxxxxxx
>> >  L: dri-devel@xxxxxxxxxxxxxxxxxxxxx
>> >  L: linaro-mm-sig@xxxxxxxxxxxxxxxx
>> >  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@xxxxxxxxxx>
>> > + *
>> > + * 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 ...
Apologies for the delay in response; was travelling for LPC and so
couldn't respond.

Yes, that is certainly the hope, but this is the first-step RFC which
would need a few more things before ION can be replaced completely.
>
>> /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



-- 
Thanks and regards,

Sumit Semwal
Kernel Team Lead - Linaro Mobile Group
Linaro.org â Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/