Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Fri, Dec 23, 2011 at 10:50 PM, Rob Clark r...@ti.com wrote: On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie airl...@gmail.com wrote: snip Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com Thanks Daniel and Dave! I guess we can start with staging for 3.3, and see how it shapes up. I will post the latest patch version pretty soon. not sure about staging, but could make sense to mark as experimental. Thanks, I will mark it experimental for the first version; we can remove that once it is more widely used and tested. Arnd, Dave: do you have any preference on the path it takes to get merged? In my mind, Linaro tree might make more sense, but I would leave it upto you gentlemen. Looks like Dave is making some progress on drm usage of buffer sharing between gpu's.. if that is ready to go in at the same time, it might be a bit logistically simpler for him to put dmabuf in the same pull req. I don't have strong preference one way or another, so do what is collectively simpler ;-) :) Right - I am quite happy for it to get merged in either ways :) BR, -R Best regards, ~Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie airl...@gmail.com wrote: snip I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com Thanks Daniel and Dave! I guess we can start with staging for 3.3, and see how it shapes up. I will post the latest patch version pretty soon. Arnd, Dave: do you have any preference on the path it takes to get merged? In my mind, Linaro tree might make more sense, but I would leave it upto you gentlemen. Dave. Best regards, ~Sumit. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Fri, Dec 23, 2011 at 4:08 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Wed, Dec 21, 2011 at 1:50 AM, Dave Airlie airl...@gmail.com wrote: snip I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com Thanks Daniel and Dave! I guess we can start with staging for 3.3, and see how it shapes up. I will post the latest patch version pretty soon. not sure about staging, but could make sense to mark as experimental. Arnd, Dave: do you have any preference on the path it takes to get merged? In my mind, Linaro tree might make more sense, but I would leave it upto you gentlemen. Looks like Dave is making some progress on drm usage of buffer sharing between gpu's.. if that is ready to go in at the same time, it might be a bit logistically simpler for him to put dmabuf in the same pull req. I don't have strong preference one way or another, so do what is collectively simpler ;-) BR, -R Dave. Best regards, ~Sumit. -- 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Wed, Dec 21, 2011 at 3:56 AM, Rob Clark r...@ti.com wrote: On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie airl...@gmail.com wrote: snip I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com fwiw, patches to share buffers between drm and v4l2 are here: https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf (need a bit of cleanup before the vb2 patches are submitted.. but that is unrelated to the dmabuf patches) so, Reviewed-and-Tested-by: Rob Clark rob.cl...@linaro.org Thanks Daniel, Dave, and Rob! BR, Sumit. Dave. -- 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need comes forth from a variety of use cases including cameras, image processing, video recorders, sound processing, DMA engines, GPU and display buffers, and others. This RFC is an attempt to define such a buffer sharing mechanism- it is the result of discussions from a couple of memory-management mini-summits held by Linaro to understand and address common needs around memory management. [1] A new dma_buf buffer object is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Documentation present in the patch-set gives more details. This is based on design suggestions from many people at the mini-summits, most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] References: [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Patchset based on top of 3.2-rc3, the current version can be found at http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git Branch: dma-buf-upstr-v2 Earlier versions: v2 at: https://lkml.org/lkml/2011/12/2/53 v1 at: https://lkml.org/lkml/2011/10/11/92 Best regards, ~Sumit Semwal I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie airl...@gmail.com wrote: This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need comes forth from a variety of use cases including cameras, image processing, video recorders, sound processing, DMA engines, GPU and display buffers, and others. This RFC is an attempt to define such a buffer sharing mechanism- it is the result of discussions from a couple of memory-management mini-summits held by Linaro to understand and address common needs around memory management. [1] A new dma_buf buffer object is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Documentation present in the patch-set gives more details. This is based on design suggestions from many people at the mini-summits, most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] References: [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Patchset based on top of 3.2-rc3, the current version can be found at http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git Branch: dma-buf-upstr-v2 Earlier versions: v2 at: https://lkml.org/lkml/2011/12/2/53 v1 at: https://lkml.org/lkml/2011/10/11/92 Best regards, ~Sumit Semwal I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com fwiw, patches to share buffers between drm and v4l2 are here: https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf (need a bit of cleanup before the vb2 patches are submitted.. but that is unrelated to the dmabuf patches) so, Reviewed-and-Tested-by: Rob Clark rob.cl...@linaro.org Dave. -- 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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
