Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
Hi Greg, Daniel! On 12 October 2014 00:10, Daniel Vetter dan...@ffwll.ch 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.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.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@vger.kernel.org L: dri-de...@lists.freedesktop.org L: linaro-mm-...@lists.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 000..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.sem...@linaro.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 ... 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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
Hi Laura,
On 13 October 2014 14:05, Laura Abbott lau...@codeaurora.org wrote:
On 10/10/2014 1:07 PM, 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.
My first instinct is 'I wonder which drivers will call map_attachment at
the wrong time and screw things up'. Are there any plans for
synchronization and/or debugging output to catch drivers violating this
requirement?
Well, of course you're right - at the moment, no mechanism to do so.
That will certainly be the next step - we could discuss it sometime
this week at LPC to see what makes better sense.
[...]
+int cenalloc_phys(struct dma_buf *dmabuf,
+phys_addr_t *addr, size_t *len)
+{
+ struct cenalloc_buffer *buffer;
+ int ret;
+
+ if (is_cenalloc_buffer(dmabuf))
+ buffer = (struct cenalloc_buffer *)dmabuf-priv;
+ else
+ return -EINVAL;
+
+ if (!buffer-allocator-ops-phys) {
+ pr_err(%s: cenalloc_phys is not implemented by this
allocator.\n,
+ __func__);
+ return -ENODEV;
+ }
+ mutex_lock(buffer-lock);
+ ret = buffer-allocator-ops-phys(buffer-allocator, buffer,
addr,
+ len);
+ mutex_lock(buffer-lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cenalloc_phys);
+
The .phys operation makes it difficult to have drivers which can
handle both contiguous and non contiguous memory (too much special
casing). Any chance we could drop this API and just have drivers
treat an sg_table with 1 entry as contiguous memory?
I am not sure I understand how having a .phys makes it more difficult
- and also, for cases where you're sharing buffers between CPU and a
co-processor like DSP, my understanding is that we'd need an
equivalent of a phys address.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
On 10/10/2014 1:07 PM, 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.
My first instinct is 'I wonder which drivers will call map_attachment at
the wrong time and screw things up'. Are there any plans for
synchronization and/or debugging output to catch drivers violating this
requirement?
[...]
+int cenalloc_phys(struct dma_buf *dmabuf,
+phys_addr_t *addr, size_t *len)
+{
+ struct cenalloc_buffer *buffer;
+ int ret;
+
+ if (is_cenalloc_buffer(dmabuf))
+ buffer = (struct cenalloc_buffer *)dmabuf-priv;
+ else
+ return -EINVAL;
+
+ if (!buffer-allocator-ops-phys) {
+ pr_err(%s: cenalloc_phys is not implemented by this
allocator.\n,
+ __func__);
+ return -ENODEV;
+ }
+ mutex_lock(buffer-lock);
+ ret = buffer-allocator-ops-phys(buffer-allocator, buffer, addr,
+ len);
+ mutex_lock(buffer-lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cenalloc_phys);
+
The .phys operation makes it difficult to have drivers which can
handle both contiguous and non contiguous memory (too much special
casing). Any chance we could drop this API and just have drivers
treat an sg_table with 1 entry as contiguous memory?
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.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@vger.kernel.org L: dri-de...@lists.freedesktop.org L: linaro-mm-...@lists.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 000..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.sem...@linaro.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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
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.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.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@vger.kernel.org L: dri-de...@lists.freedesktop.org L: linaro-mm-...@lists.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 000..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.sem...@linaro.org + * + * Structure for management of clients, buffers etc heavily derived from + * Android's ION framework. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/device.h +#include linux/err.h +#include linux/file.h +#include linux/fs.h +#include linux/miscdevice.h +#include linux/rbtree.h +#include linux/slab.h +#include linux/vmalloc.h +#include linux/debugfs.h +#include linux/module.h + +#include cenalloc.h +#include cenalloc_priv.h + +/* + * Constraints-aware allocator framework helper is meant to facilitate + * deferred allocation of backing storage for dma-buf buffers. + * It works for devices that can share their constraints via dma_params. + * These dma_params are then used by dma_buf_attach() to create a mask of + * common constraints. The cenalloc constraint helpers then allocate + * for the preferred allocator according to the constraint mask. + * Allocators and their corresponding constraint masks are pre-populated + * for a given system - likely at the time of platform initialization. + */ +/** + * struct cenalloc_device - the metadata of the cenalloc device node + * @dev: the actual misc device + * @buffers: an rb tree of all the
Re: [RFC 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
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.sem...@linaro.org Cc: linux-ker...@vger.kernel.org Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: linux-media@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.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@vger.kernel.org L: dri-de...@lists.freedesktop.org L: linaro-mm-...@lists.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 000..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.sem...@linaro.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? /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-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
