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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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
[Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
On Thu June 7 2012 02:52:06 Laurent Pinchart wrote: > 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. 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'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, Hans
[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
Re: [Linaro-mm-sig] [PATCHv6 00/13] Integration of videobuf2 with dmabuf
On Thu June 7 2012 02:52:06 Laurent Pinchart wrote: 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. 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'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, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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
[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
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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-sig at lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-mm-sig >
[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
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 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
>> 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
>>> wrote:
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
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
[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
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 wrote:
>> On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
>> 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
[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
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
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
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[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 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
[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
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 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
>> 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
>>> wrote:
On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
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
[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 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
> 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
>> wrote:
>>> On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
>>> 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):
[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 wrote:
> On Tue, May 29, 2012 at 6:25 AM, Laurent Pinchart
> 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 |
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
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
