Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi, On 06/07/2012 08:43 AM, Hans Verkuil wrote: On Thu June 7 2012 02:52:06 Laurent Pinchart wrote: On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote: On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote: On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? data_offset is indeed for video output only at the moment, and doesn't seem to be used by any driver in mainline for now. Actually, data_offset may be set by capture drivers. For output buffers it is set by userspace, for capture buffers it is set by the driver. This data_offset typically contains meta data. Is that documented somewhere ? I wasn't aware of this use case. It is documented in the proposal that Pawel sent, but very poorly if at all in the spec. That needs to be improved. I can't really see a reason why data_offset couldn't be used for video capture devices as well. Sanity checks are currently missing. For output devices we should check that data_offset + bytesused length in the vb2 core. For input devices the check will have to be performed by drivers. Taking data_offset into account automatically would also be useful. I think most of that should be possible to implement in the allocators. See this proposal of how to solve this: http://www.spinics.net/lists/linux-media/msg40376.html This requires more discussions regarding how the app_offset and data_offset fields should be used for the different memory types we support. For instance app_offset would not make that much sense for the USERPTR memory type, as we can include the offset in the user pointer already (using app_offset there would only make the code more complex without any added benefit). For the MMAP memory type adding an app_offset would require allocating buffers large enough to accomodate the offset, and would thus only be useful with CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer to another device that requires that app_offset) wouldn't be better addressed by the DMABUF memory type anyway. I think what is needed is a more flexible support for multi-planar data formats. Currently each plane involves separate memory allocation, which is not convenient in some use cases, at the least. For each plane a separate DMABUF object is needed. Single allocation for several data planes could be also useful for some still image capture use cases, where an image sensor device outputs multiple data at once, which can only be written into single memory region. There is currently no standard way to retrieve data offsets and sizes in such cases. It likely won't be trivial to cleanly integrate support for this with current V4L2 multi-plane API though. I'm not going to pursue this unless Google indicates that they need this. And actually I would suggest that they ask Pawel to work on this, after all he made the proposal AND he works for Google :-) -- Regards, Sylwester -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote: Hi Rebecca, On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? data_offset is indeed for video output only at the moment, and doesn't seem to be used by any driver in mainline for now. Actually, data_offset may be set by capture drivers. For output buffers it is set by userspace, for capture buffers it is set by the driver. This data_offset typically contains meta data. I can't really see a reason why data_offset couldn't be used for video capture devices as well. Sanity checks are currently missing. For output devices we should check that data_offset + bytesused length in the vb2 core. For input devices the check will have to be performed by drivers. Taking data_offset into account automatically would also be useful. I think most of that should be possible to implement in the allocators. See this proposal of how to solve this: http://www.spinics.net/lists/linux-media/msg40376.html Regards, Hans -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi Hans, On Wednesday 06 June 2012 10:17:03 Hans Verkuil wrote: On Wed 6 June 2012 05:46:34 Laurent Pinchart wrote: On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? data_offset is indeed for video output only at the moment, and doesn't seem to be used by any driver in mainline for now. Actually, data_offset may be set by capture drivers. For output buffers it is set by userspace, for capture buffers it is set by the driver. This data_offset typically contains meta data. Is that documented somewhere ? I wasn't aware of this use case. I can't really see a reason why data_offset couldn't be used for video capture devices as well. Sanity checks are currently missing. For output devices we should check that data_offset + bytesused length in the vb2 core. For input devices the check will have to be performed by drivers. Taking data_offset into account automatically would also be useful. I think most of that should be possible to implement in the allocators. See this proposal of how to solve this: http://www.spinics.net/lists/linux-media/msg40376.html This requires more discussions regarding how the app_offset and data_offset fields should be used for the different memory types we support. For instance app_offset would not make that much sense for the USERPTR memory type, as we can include the offset in the user pointer already (using app_offset there would only make the code more complex without any added benefit). For the MMAP memory type adding an app_offset would require allocating buffers large enough to accomodate the offset, and would thus only be useful with CREATE_BUFS. I'm also wondering whether the main use case (passing the buffer to another device that requires that app_offset) wouldn't be better addressed by the DMABUF memory type anyway. Comments are welcome. -- Regards, Laurent Pinchart -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
On Mon June 4 2012 23:58:07 Hans Verkuil wrote: Hi Rebecca, On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? v4l2_plane is typically used if the planes are allocated separately. If you allocate it in one go, aren't the planes then at well-defined offsets from the start? If so, then it is either one of the already pre-defined planar formats found here: http://hverkuil.home.xs4all.nl/spec/media.html#yuv-formats or you define a pixelformat specific to your own hardware that identifies that particular format. If it is one allocation, but there is no clear calculation based on width and height that gives you the start of each plane, then we do not support that at the moment. I believe I had a discussion about something similar with people from Qualcomm, but that never came to anything. It took some digging, but this was the enhancement proposed for a Qualcomm problem: http://www.spinics.net/lists/linux-media/msg40376.html This may or may not be what you are looking for. Regards, Hans That would be something to discuss on the linux-media mailinglist. Regards, Hans ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi Rebecca, On Monday 04 June 2012 12:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? data_offset is indeed for video output only at the moment, and doesn't seem to be used by any driver in mainline for now. I can't really see a reason why data_offset couldn't be used for video capture devices as well. Sanity checks are currently missing. For output devices we should check that data_offset + bytesused length in the vb2 core. For input devices the check will have to be performed by drivers. Taking data_offset into account automatically would also be useful. I think most of that should be possible to implement in the allocators. -- Regards, Laurent Pinchart -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? Thanks, Rebecca On Wed, May 30, 2012 at 8:26 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, Hi Tomasz, Laurent, Mauro, On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Except for the small issue with patches 01/13 and 02/13, the set is ready for upstream as far as I'm concerned. +1; Mauro: how do you think about this series? Getting it landed into 3.5 would make life lot easier :) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure I've missed that one, what was it ? - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296 6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635 4/focus=36355 [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (5): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: Remove unneeded allocation context structure v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation/DocBook/media/v4l/compat.xml | 4 + Documentation/DocBook/media/v4l/io.xml | 179 +++ .../DocBook/media/v4l/vidioc-create-bufs.xml | 1 + Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 15 + Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 45 +- drivers/media/video/s5p-fimc/Kconfig | 1 + drivers/media/video/s5p-fimc/fimc-capture.c | 2 +- drivers/media/video/s5p-tv/Kconfig | 1 + drivers/media/video/s5p-tv/mixer_video.c
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
this is at least how we do it w/ drm/kms.. I would expect that if you could do that w/ output for v4l you also could for input, but perhaps the individual driver needs to do something to support mplane? I guess the v4l folks would know better BR, -R On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin rebe...@android.com wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? Thanks, Rebecca On Wed, May 30, 2012 at 8:26 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, Hi Tomasz, Laurent, Mauro, On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Except for the small issue with patches 01/13 and 02/13, the set is ready for upstream as far as I'm concerned. +1; Mauro: how do you think about this series? Getting it landed into 3.5 would make life lot easier :) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure I've missed that one, what was it ? - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296 6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635 4/focus=36355 [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (5): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: Remove unneeded allocation context structure v4l: vb2-dma-contig: add support for scatterlist in userptr mode v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-fimc: support for dmabuf importing Documentation/DocBook/media/v4l/compat.xml | 4 + Documentation/DocBook/media/v4l/io.xml | 179 +++ .../DocBook/media/v4l/vidioc-create-bufs.xml | 1 +
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
I'm trying to do it in my drivier, but I'm not sure how to make it safe since there is no way to tell the kernel the total size of the buffer. From what I can tell, I can't sanity check that the offset and lengths are within the buffer without adding a field. Rebecca On Mon, Jun 4, 2012 at 1:28 PM, Rob Clark robdcl...@gmail.com wrote: this is at least how we do it w/ drm/kms.. I would expect that if you could do that w/ output for v4l you also could for input, but perhaps the individual driver needs to do something to support mplane? I guess the v4l folks would know better BR, -R On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin rebe...@android.com wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? Thanks, Rebecca On Wed, May 30, 2012 at 8:26 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, Hi Tomasz, Laurent, Mauro, On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Except for the small issue with patches 01/13 and 02/13, the set is ready for upstream as far as I'm concerned. +1; Mauro: how do you think about this series? Getting it landed into 3.5 would make life lot easier :) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure I've missed that one, what was it ? - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296 6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635 4/focus=36355 [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (5): Documentation: media: description of DMABUF importing in V4L2 v4l: vb2-dma-contig: Remove unneeded allocation context structure v4l: vb2-dma-contig: add
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Also the data_offset field (and bytes_used field) only get copied from the v4l2_buffer into the vb2_buffer struct if the buffer is an output buffer. Rebecca On Mon, Jun 4, 2012 at 1:46 PM, Rebecca Schultz Zavin rebe...@android.com wrote: I'm trying to do it in my drivier, but I'm not sure how to make it safe since there is no way to tell the kernel the total size of the buffer. From what I can tell, I can't sanity check that the offset and lengths are within the buffer without adding a field. Rebecca On Mon, Jun 4, 2012 at 1:28 PM, Rob Clark robdcl...@gmail.com wrote: this is at least how we do it w/ drm/kms.. I would expect that if you could do that w/ output for v4l you also could for input, but perhaps the individual driver needs to do something to support mplane? I guess the v4l folks would know better BR, -R On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin rebe...@android.com wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? Thanks, Rebecca On Wed, May 30, 2012 at 8:26 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, Hi Tomasz, Laurent, Mauro, On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Except for the small issue with patches 01/13 and 02/13, the set is ready for upstream as far as I'm concerned. +1; Mauro: how do you think about this series? Getting it landed into 3.5 would make life lot easier :) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure I've missed that one, what was it ? - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296 6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635 4/focus=36355 [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
can you check expected size vs dmabuf-size - offset? On Tue, Jun 5, 2012 at 4:46 AM, Rebecca Schultz Zavin rebe...@android.com wrote: I'm trying to do it in my drivier, but I'm not sure how to make it safe since there is no way to tell the kernel the total size of the buffer. From what I can tell, I can't sanity check that the offset and lengths are within the buffer without adding a field. Rebecca On Mon, Jun 4, 2012 at 1:28 PM, Rob Clark robdcl...@gmail.com wrote: this is at least how we do it w/ drm/kms.. I would expect that if you could do that w/ output for v4l you also could for input, but perhaps the individual driver needs to do something to support mplane? I guess the v4l folks would know better BR, -R On Tue, Jun 5, 2012 at 3:34 AM, Rebecca Schultz Zavin rebe...@android.com wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? Thanks, Rebecca On Wed, May 30, 2012 at 8:26 AM, Semwal, Sumit sumit.sem...@ti.com wrote: On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, Hi Tomasz, Laurent, Mauro, On Wednesday 23 May 2012 14:10:14 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Except for the small issue with patches 01/13 and 02/13, the set is ready for upstream as far as I'm concerned. +1; Mauro: how do you think about this series? Getting it landed into 3.5 would make life lot easier :) v6: - fixed missing entry in v4l2_memory_names - fixed a bug occuring after get_user_pages failure I've missed that one, what was it ? - fixed a bug caused by using invalid vma for get_user_pages - prepare/finish no longer call dma_sync for dmabuf buffers v5: - removed change of importer/exporter behaviour - fixes vb2_dc_pages_to_sgt basing on Laurent's hints - changed pin/unpin words to lock/unlock in Doc v4: - rebased on mainline 3.4-rc2 - included missing importing support for s5p-fimc and s5p-tv - added patch for changing map/unmap for importers - fixes to Documentation part - coding style fixes - pairing {map/unmap}_dmabuf in vb2-core - fixing variable types and semantic of arguments in videobufb2-dma-contig.c v3: - rebased on mainline 3.4-rc1 - split 'code refactor' patch to multiple smaller patches - squashed fixes to Sumit's patches - patchset is no longer dependant on 'DMA mapping redesign' - separated path for handling IO and non-IO mappings - add documentation for DMABUF importing to V4L - removed all DMABUF exporter related code - removed usage of dma_get_pages extension v2: - extended VIDIOC_EXPBUF argument from integer memoffset to struct v4l2_exportbuffer - added patch that breaks DMABUF spec on (un)map_atachment callcacks but allows to work with existing implementation of DMABUF prime in DRM - all dma-contig code refactoring patches were squashed - bugfixes v1: List of changes since [1]. - support for DMA api extension dma_get_pages, the function is used to retrieve pages used to create DMA mapping. - small fixes/code cleanup to videobuf2 - added prepare and finish callbacks to vb2 allocators, it is used keep consistency between dma-cpu acess to the memory (by Marek Szyprowski) - support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated from [3]. - support for dma-buf exporting in vb2-dma-contig allocator - support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers, originated from [3] - changed handling for userptr buffers (by Marek Szyprowski, Andrzej Pietrasiewicz) - let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski) [1] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4296 6/focus=42968 [2] https://lkml.org/lkml/2011/12/26/29 [3] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/3635 4/focus=36355 [4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 Laurent Pinchart (2): v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc v4l: vb2-dma-contig: Reorder functions Marek Szyprowski (2): v4l: vb2: add prepare/finish callbacks to allocators v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Sumit Semwal (4): v4l: Add DMABUF as a memory type v4l: vb2: add support for shared buffer (dma_buf) v4l: vb: remove warnings about MEMORY_DMABUF v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski (5): Documentation:
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
Hi Rebecca, On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? v4l2_plane is typically used if the planes are allocated separately. If you allocate it in one go, aren't the planes then at well-defined offsets from the start? If so, then it is either one of the already pre-defined planar formats found here: http://hverkuil.home.xs4all.nl/spec/media.html#yuv-formats or you define a pixelformat specific to your own hardware that identifies that particular format. If it is one allocation, but there is no clear calculation based on width and height that gives you the start of each plane, then we do not support that at the moment. I believe I had a discussion about something similar with people from Qualcomm, but that never came to anything. That would be something to discuss on the linux-media mailinglist. Regards, Hans -- 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] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
It probably is a fixed offset, but all the information describing it is in userspace... In my experience, it's always almost one of the pre-defined formats, but then there's some extra padding, weird alignment etc. I'm trying to convert code that used userptr, but where the planes were offsets into the same buffer, to use dma_buf. Looks like I need to dig a bit deeper. Thanks, Rebecca On Mon, Jun 4, 2012 at 2:58 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Rebecca, On Mon June 4 2012 21:34:23 Rebecca Schultz Zavin wrote: I have a system where the data is planar, but the kernel drivers expect to get one allocation with offsets for the planes. I can't figure out how to do that with the current dma_buf implementation. I thought I could pass the same dma_buf several times and use the data_offset field of the v4l2_plane struct but it looks like that's only for output. Am I missing something? Is this supported? v4l2_plane is typically used if the planes are allocated separately. If you allocate it in one go, aren't the planes then at well-defined offsets from the start? If so, then it is either one of the already pre-defined planar formats found here: http://hverkuil.home.xs4all.nl/spec/media.html#yuv-formats or you define a pixelformat specific to your own hardware that identifies that particular format. If it is one allocation, but there is no clear calculation based on width and height that gives you the start of each plane, then we do not support that at the moment. I believe I had a discussion about something similar with people from Qualcomm, but that never came to anything. That would be something to discuss on the linux-media mailinglist. Regards, Hans -- 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