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

[Greg Kroah-Hartman]

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?

/me dreams

Anyway, why a new directory?  Why not just put it in drivers/dma-buf ?
Or a subdir below there?

thanks,

greg k-h
--
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/