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
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 -- 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 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: [RFC/PATCH v2] media: Add stk1160 new driver
On Mon June 4 2012 21:50:46 Ezequiel Garcia wrote:
> On Mon, Jun 4, 2012 at 5:47 AM, Hans Verkuil wrote:
> >
> >> Would you care to explain me this change in your patch?
> >> + set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
> >
> > See Documentation/video4linux/v4l2-framework.txt:
> >
> > "flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the
> > framework
> > handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
> > v4l2_fh. Eventually this flag will disappear once all drivers use the core
> > priority handling. But for now it has to be set explicitly."
> >
>
> So, by using v4l2_fh and setting V4L2_FL_USE_FH_PRIO, I can have
> {g,s}_priority ioctls for free, right?
Yes.
> As far as I can see __video_do_ioctl checks if the ioctl is possible, like
> this:
>
> 520 if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)) {
> 521 vfh = file->private_data;
> 522 use_fh_prio = test_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
> 523 }
> 524
> 525 if (use_fh_prio)
> 526 ret_prio = v4l2_prio_check(vfd->prio, vfh->prio);
And V4L2_FL_USES_V4L2_FH is set by v4l2_fh_init() (called by v4l2_fh_open()).
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
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
>
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
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
>>
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 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):
>
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
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 u
Re: [RFC/PATCH v2] media: Add stk1160 new driver
On Mon, Jun 4, 2012 at 5:47 AM, Hans Verkuil wrote:
>
>> Would you care to explain me this change in your patch?
>> + set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
>
> See Documentation/video4linux/v4l2-framework.txt:
>
> "flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
> handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
> v4l2_fh. Eventually this flag will disappear once all drivers use the core
> priority handling. But for now it has to be set explicitly."
>
So, by using v4l2_fh and setting V4L2_FL_USE_FH_PRIO, I can have
{g,s}_priority ioctls for free, right?
As far as I can see __video_do_ioctl checks if the ioctl is possible, like this:
520 if (test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags)) {
521 vfh = file->private_data;
522 use_fh_prio = test_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
523 }
524
525 if (use_fh_prio)
526 ret_prio = v4l2_prio_check(vfd->prio, vfh->prio);
Just checking,
Thanks!
Ezequiel.
--
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 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: Doing a new upstream / linuxtv.org xawtv3 release?
Hello, On 6/4/12 12:57 PM, Hans de Goede wrote: > I've been doing a lot of work on xawtv3 lately, mostly on the radio app > but also some on xawtv itself. I'm no done and IMHO it would be good > to do a new upstream release to get all those changes out there. > > So any comments / suggestions? Note "go for it" also is a valid > comment :) The Debian patch tracker contains four patches for xawtv: http://patch-tracker.debian.org/package/xawtv/3.102-3 Three of them are already in the git tree, this one is not: > http://patch-tracker.debian.org/patch/series/view/xawtv/3.102-3/mtt_only_in_linux Could you please add it before the release? Thanks, Gregor -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jun 4 19:00:20 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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
SH7724, VOU, PAL mode
Hi Guennadi. I am trying to force to proper work CS4954 encoder with sh4. I want to use sh4 VOU in PAL mode (kernel 3.2.7). Do you have any experience with AK881x and PAL? If I set PAL mode (v4l2-ctl -s) VOUCR::MD is still configured for NTSC. I noticed that VOU is limited to NTSC resolution: "Maximum destination image size: 720 x 240 per field". And indeed I had to change my encoder settings to NTSC-M CCIR601 timing 720x480 (PAL synch freq. only) for synced (stable) color video picture of BAR generated by the encoder (not VOU). On the other hand VOUDSR register has bit-limit 1024x512 (enough for PAL 768x576 interlaced). Another method for stable PAL picture (but 768x576) is change both VOUCR::MD to PAL output mode and set the encoder to PAL mode. Then the green picture has a bound about 480 line I think. Unfortunately I can't still manage to work video data from VOU to the encoder - green picture only. Do you have any test program for video v4l2 output? Does the idea fb->v4l2 output http://www.spinics.net/lists/linux-fbdev/msg01102.html is alive? best regards Janusz Uzycki ELPROMA -- 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
[PATCH] [media] lirc_sir: make device registration work
For one, the driver device pointer needs to be filled in, or the lirc core
will refuse to load the driver. And we really need to wire up all the
platform_device bits. This has been tested via the lirc sourceforge tree
and verified to work, been sitting there for months, finally getting
around to sending it. :\
CC: Josh Boyer
CC: Mauro Carvalho Chehab
Signed-off-by: Jarod Wilson
---
drivers/staging/media/lirc/lirc_sir.c | 60 +++-
1 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_sir.c
b/drivers/staging/media/lirc/lirc_sir.c
index 945d962..4afc3b4 100644
--- a/drivers/staging/media/lirc/lirc_sir.c
+++ b/drivers/staging/media/lirc/lirc_sir.c
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#ifdef LIRC_ON_SA1100
#include
#ifdef CONFIG_SA1100_COLLIE
@@ -487,9 +488,11 @@ static struct lirc_driver driver = {
.owner = THIS_MODULE,
};
+static struct platform_device *lirc_sir_dev;
static int init_chrdev(void)
{
+ driver.dev = &lirc_sir_dev->dev;
driver.minor = lirc_register_driver(&driver);
if (driver.minor < 0) {
printk(KERN_ERR LIRC_DRIVER_NAME ": init_chrdev() failed.\n");
@@ -1215,20 +1218,71 @@ static int init_lirc_sir(void)
return 0;
}
+static int __devinit lirc_sir_probe(struct platform_device *dev)
+{
+ return 0;
+}
+
+static int __devexit lirc_sir_remove(struct platform_device *dev)
+{
+ return 0;
+}
+
+static struct platform_driver lirc_sir_driver = {
+ .probe = lirc_sir_probe,
+ .remove = __devexit_p(lirc_sir_remove),
+ .driver = {
+ .name = "lirc_sir",
+ .owner = THIS_MODULE,
+ },
+};
static int __init lirc_sir_init(void)
{
int retval;
+ retval = platform_driver_register(&lirc_sir_driver);
+ if (retval) {
+ printk(KERN_ERR LIRC_DRIVER_NAME ": Platform driver register "
+ "failed!\n");
+ return -ENODEV;
+ }
+
+ lirc_sir_dev = platform_device_alloc("lirc_dev", 0);
+ if (!lirc_sir_dev) {
+ printk(KERN_ERR LIRC_DRIVER_NAME ": Platform device alloc "
+ "failed!\n");
+ retval = -ENOMEM;
+ goto pdev_alloc_fail;
+ }
+
+ retval = platform_device_add(lirc_sir_dev);
+ if (retval) {
+ printk(KERN_ERR LIRC_DRIVER_NAME ": Platform device add "
+ "failed!\n");
+ retval = -ENODEV;
+ goto pdev_add_fail;
+ }
+
retval = init_chrdev();
if (retval < 0)
- return retval;
+ goto fail;
+
retval = init_lirc_sir();
if (retval) {
drop_chrdev();
- return retval;
+ goto fail;
}
+
return 0;
+
+fail:
+ platform_device_del(lirc_sir_dev);
+pdev_add_fail:
+ platform_device_put(lirc_sir_dev);
+pdev_alloc_fail:
+ platform_driver_unregister(&lirc_sir_driver);
+ return retval;
}
static void __exit lirc_sir_exit(void)
@@ -1236,6 +1290,8 @@ static void __exit lirc_sir_exit(void)
drop_hardware();
drop_chrdev();
drop_port();
+ platform_device_unregister(lirc_sir_dev);
+ platform_driver_unregister(&lirc_sir_driver);
printk(KERN_INFO LIRC_DRIVER_NAME ": Uninstalled.\n");
}
--
1.7.1
--
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: [PATCH] [media] soc-camera: Correct icl platform data assignment
Hi, Guennadi Got it! Thank you! We will update our client driver. Thanks Albert Wang 86-21-61092656 -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Monday, 04 June, 2012 23:49 To: Albert Wang Cc: linux-media@vger.kernel.org Subject: RE: [PATCH] [media] soc-camera: Correct icl platform data assignment On Mon, 4 Jun 2012, Albert Wang wrote: > Hi, Guennadi > > Yes, maybe you are right. > I checked some i2c client drivers, they all changed it to: > > struct soc_camera_link *icl = soc_camera_i2c_to_link(client); > > We also can update our client driver, but could you please explain why > do you change it? Since you have already found the change, you could also use git blame to find this commit: commit b569a3766136e710883a16a91cd12942560e772b Author: Guennadi Liakhovetski Date: Wed Sep 21 20:16:30 2011 +0200 V4L: soc-camera: start removing struct soc_camera_device from client drivers Remove most trivial uses of struct soc_camera_device from most client drivers, abstracting some of them inside inline functions. Next steps will eliminate remaining uses and modify inline functions to not use struct soc_camera_device. I.e., client drivers should become independent of soc-camera, that's why they shoudn't access struct soc_camera_device. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
On Mon, Jun 04, 2012 at 06:40:46PM +0200, Laurent Pinchart wrote: > Hi Felipe, > > On Monday 04 June 2012 18:28:33 Felipe Balbi wrote: > > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > > > On Monday, June 04, 2012 8:44 PM Felipe Balbi wrote: > > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > > > This patch reworks the videobuffer management logic present in the > > > > > UVC webcam gadget and ports it to use the "more apt" videobuf2 > > > > > framework for video buffer management. > > > > > > > > > > To support routing video data captured from a real V4L2 video capture > > > > > device with a "zero copy" operation on videobuffers (as they pass from > > > > > the V4L2 domain to UVC domain via a user-space application), we need > > > > > to support USER_PTR IO method at the UVC gadget side. > > > > > > > > > > So the V4L2 capture device driver can still continue to use MMAO IO > > > > > method and now the user-space application can just pass a pointer to > > > > > the video buffers being DeQueued from the V4L2 device side while > > > > > Queueing them at the UVC gadget end. This ensures that we have a > > > > > "zero-copy" design as the videobuffers pass from the V4L2 capture > > > > > device to the UVC gadget. > > > > > > > > > > Note that there will still be a need to apply UVC specific payload > > > > > headers on top of each UVC payload data, which will still require a > > > > > copy operation to be performed in the 'encode' routines of the UVC > > > > > gadget. > > > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my gadget > > > > branch which I will update in a while. > > > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > > > Should I now refresh my patches on top of your "v3.5-rc1" branch ? > > > > > > I am a bit confused on what is the latest gadget branch to be used now. > > > Thanks for helping out. > > > > The gadget branch is the branch called gadget on my kernel.org tree. For > > some reason this didn't apply. Probably some patches on > > drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. Possibly > > because I was out for quite a while and asked Greg to help me out during > > the merge window. > > > > Anyway, I just pushed gadget with a bunch of new patches and part of > > your series. > > I would have appreciated an occasion to review them first (especially 3/5 > which should *really* have been split into several patches) :-( Have they > been > pushed to mainline yet ? on my branch only, but I don't plan to rebase as that would screw up my git objects. > I'm currently traveling to Japan for LinuxCon so I won't have time to look > into this before next week. I'll send incremental patches to fix issues with > the already applied patches, *please* don't apply 4/5 and 5/5 before I can > review them. sure, no problem... Will wait. -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Felipe, On Monday 04 June 2012 18:28:33 Felipe Balbi wrote: > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > > On Monday, June 04, 2012 8:44 PM Felipe Balbi wrote: > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > > This patch reworks the videobuffer management logic present in the > > > > UVC webcam gadget and ports it to use the "more apt" videobuf2 > > > > framework for video buffer management. > > > > > > > > To support routing video data captured from a real V4L2 video capture > > > > device with a "zero copy" operation on videobuffers (as they pass from > > > > the V4L2 domain to UVC domain via a user-space application), we need > > > > to support USER_PTR IO method at the UVC gadget side. > > > > > > > > So the V4L2 capture device driver can still continue to use MMAO IO > > > > method and now the user-space application can just pass a pointer to > > > > the video buffers being DeQueued from the V4L2 device side while > > > > Queueing them at the UVC gadget end. This ensures that we have a > > > > "zero-copy" design as the videobuffers pass from the V4L2 capture > > > > device to the UVC gadget. > > > > > > > > Note that there will still be a need to apply UVC specific payload > > > > headers on top of each UVC payload data, which will still require a > > > > copy operation to be performed in the 'encode' routines of the UVC > > > > gadget. > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my gadget > > > branch which I will update in a while. > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > > Should I now refresh my patches on top of your "v3.5-rc1" branch ? > > > > I am a bit confused on what is the latest gadget branch to be used now. > > Thanks for helping out. > > The gadget branch is the branch called gadget on my kernel.org tree. For > some reason this didn't apply. Probably some patches on > drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. Possibly > because I was out for quite a while and asked Greg to help me out during > the merge window. > > Anyway, I just pushed gadget with a bunch of new patches and part of > your series. I would have appreciated an occasion to review them first (especially 3/5 which should *really* have been split into several patches) :-( Have they been pushed to mainline yet ? I'm currently traveling to Japan for LinuxCon so I won't have time to look into this before next week. I'll send incremental patches to fix issues with the already applied patches, *please* don't apply 4/5 and 5/5 before I can review them. -- 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: OMAP 3 ISP
Hi Ritesh, On Thursday 31 May 2012 03:26:57 Ritesh wrote: > Hi Laurent, > For me even ISP revision print log is not displaying and moreover when I am > checking the interrupts using cat /proc/interrupts > Only iommu interrupt is showing for interrupt line 24 > > Seems ISP probe function is not at all getting called > Right now board is not available for me so that I can't post here complete > log > > Can u please send me working Linux kernel repository link for omap35x > torpedo kit I can't, as I don't have that. You should take the latest mainline code and add ISP board code for your board. You can find examples of such board code at http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- sensors-board for the Beagleboard, the Gumstix Overo and the OMAP3 EVM. -- 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: [PATCH] [media] soc-camera: Correct icl platform data assignment
On Mon, 4 Jun 2012, Albert Wang wrote: > Hi, Guennadi > > Yes, maybe you are right. > I checked some i2c client drivers, they all changed it to: > > struct soc_camera_link *icl = soc_camera_i2c_to_link(client); > > We also can update our client driver, but could you please explain why > do you change it? Since you have already found the change, you could also use git blame to find this commit: commit b569a3766136e710883a16a91cd12942560e772b Author: Guennadi Liakhovetski Date: Wed Sep 21 20:16:30 2011 +0200 V4L: soc-camera: start removing struct soc_camera_device from client drivers Remove most trivial uses of struct soc_camera_device from most client drivers, abstracting some of them inside inline functions. Next steps will eliminate remaining uses and modify inline functions to not use struct soc_camera_device. I.e., client drivers should become independent of soc-camera, that's why they shoudn't access struct soc_camera_device. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Felipe, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, June 04, 2012 9:11 PM > To: Bhupesh SHARMA > Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux- > u...@vger.kernel.org; linux-media@vger.kernel.org; > gre...@linuxfoundation.org > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use > videobuf2 framework > > Hi, > > On Mon, Jun 04, 2012 at 11:37:59PM +0800, Bhupesh SHARMA wrote: > > > -Original Message- > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Monday, June 04, 2012 8:59 PM > > > To: Bhupesh SHARMA > > > Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux- > > > u...@vger.kernel.org; linux-media@vger.kernel.org; > > > gre...@linuxfoundation.org > > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to > > > use > > > videobuf2 framework > > > > > > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > > > > Hi Felipe, > > > > > > > > > -Original Message- > > > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > > > Sent: Monday, June 04, 2012 8:44 PM > > > > > To: Bhupesh SHARMA > > > > > Cc: laurent.pinch...@ideasonboard.com; > > > > > linux-...@vger.kernel.org; ba...@ti.com; > > > > > linux-media@vger.kernel.org; gre...@linuxfoundation.org > > > > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam > gadget > > > > > to use > > > > > videobuf2 framework > > > > > > > > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > > > > This patch reworks the videobuffer management logic present > in > > > the > > > > > UVC > > > > > > webcam gadget and ports it to use the "more apt" videobuf2 > > > > > > framework for video buffer management. > > > > > > > > > > > > To support routing video data captured from a real V4L2 video > > > > > > capture device with a "zero copy" operation on videobuffers > > > > > > (as they pass > > > > > from > > > > > > the V4L2 domain to UVC domain via a user-space application), > > > > > > we need to support USER_PTR IO method at the UVC gadget side. > > > > > > > > > > > > So the V4L2 capture device driver can still continue to use > > > > > > MMAO IO method and now the user-space application can just > > > > > > pass a pointer to the video buffers being DeQueued from the > > > > > > V4L2 device side while Queueing them at the UVC gadget end. > > > > > > This ensures that we have a "zero-copy" design as the > > > > > > videobuffers pass from the > > > > > > V4L2 capture > > > > > device to the UVC gadget. > > > > > > > > > > > > Note that there will still be a need to apply UVC specific > > > payload > > > > > > headers on top of each UVC payload data, which will still > > > > > > require a copy operation to be performed in the 'encode' > > > > > > routines of the UVC > > > > > gadget. > > > > > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > > > > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or > > > > > my gadget branch which I will update in a while. > > > > > > > > > > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > > > > Should I now refresh my patches on top of your "v3.5-rc1" branch > ? > > > > > > > > I am a bit confused on what is the latest gadget branch to be > used > > > now. > > > > Thanks for helping out. > > > > > > The gadget branch is the branch called gadget on my kernel.org > tree. > > > For some reason this didn't apply. Probably some patches on > > > drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. > > > Possibly because I was out for quite a while and asked Greg to help > > > me out during the merge window. > > > > > > Anyway, I just pushed gadget with a bunch of new patches and part > of > > > your series. > > > > > > > Yes. I had sent two patches some time ago for > drivers/usb/gadget/*uvc*. > > For one of them I received an *applied* message from you: > > that was already applied long ago. ;-) > > > > > > > usb: gadget/uvc: Remove non-required locking from > > > > 'uvc_queue_next_buffer' routine > > > > > > This patch removes the non-required spinlock acquire/release > calls > > > > on 'queue->irqlock' from 'uvc_queue_next_buffer' routine. > > > > > > > > This routine is called from 'video->encode' function (which > > > translates > > > > to either 'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in > > > 'uvc_video.c'. > > > > As, the 'video->encode' routines are called with 'queue->irqlock' > > > > already held, so acquiring a 'queue->irqlock' again in > > > > 'uvc_queue_next_buffer' routine causes a spin lock recursion. > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > Acked-by: Laurent Pinchart > > > > > > applied, thanks > > > > Not sure, if that can cause the merge conflict issue. > > So now, should I send a clean patchset on top of your 3.5-rc1 branch > > to ensure the entire new patchset for drivers/usb/gadget/*uvc* is > pulled properly? > > Yes please, just give kernel.org about 20 minutes to sync al
Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi, On Mon, Jun 04, 2012 at 11:37:59PM +0800, Bhupesh SHARMA wrote: > > -Original Message- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Monday, June 04, 2012 8:59 PM > > To: Bhupesh SHARMA > > Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux- > > u...@vger.kernel.org; linux-media@vger.kernel.org; > > gre...@linuxfoundation.org > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use > > videobuf2 framework > > > > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > > > Hi Felipe, > > > > > > > -Original Message- > > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > > Sent: Monday, June 04, 2012 8:44 PM > > > > To: Bhupesh SHARMA > > > > Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org; > > > > ba...@ti.com; linux-media@vger.kernel.org; > > > > gre...@linuxfoundation.org > > > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to > > > > use > > > > videobuf2 framework > > > > > > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > > > This patch reworks the videobuffer management logic present in > > the > > > > UVC > > > > > webcam gadget and ports it to use the "more apt" videobuf2 > > > > > framework for video buffer management. > > > > > > > > > > To support routing video data captured from a real V4L2 video > > > > > capture device with a "zero copy" operation on videobuffers (as > > > > > they pass > > > > from > > > > > the V4L2 domain to UVC domain via a user-space application), we > > > > > need to support USER_PTR IO method at the UVC gadget side. > > > > > > > > > > So the V4L2 capture device driver can still continue to use MMAO > > > > > IO method and now the user-space application can just pass a > > > > > pointer to the video buffers being DeQueued from the V4L2 device > > > > > side while Queueing them at the UVC gadget end. This ensures that > > > > > we have a "zero-copy" design as the videobuffers pass from the > > > > > V4L2 capture > > > > device to the UVC gadget. > > > > > > > > > > Note that there will still be a need to apply UVC specific > > payload > > > > > headers on top of each UVC payload data, which will still require > > > > > a copy operation to be performed in the 'encode' routines of the > > > > > UVC > > > > gadget. > > > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my > > > > gadget branch which I will update in a while. > > > > > > > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > > > Should I now refresh my patches on top of your "v3.5-rc1" branch ? > > > > > > I am a bit confused on what is the latest gadget branch to be used > > now. > > > Thanks for helping out. > > > > The gadget branch is the branch called gadget on my kernel.org tree. > > For some reason this didn't apply. Probably some patches on > > drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. Possibly > > because I was out for quite a while and asked Greg to help me out > > during the merge window. > > > > Anyway, I just pushed gadget with a bunch of new patches and part of > > your series. > > > > Yes. I had sent two patches some time ago for drivers/usb/gadget/*uvc*. > For one of them I received an *applied* message from you: that was already applied long ago. ;-) > > > > usb: gadget/uvc: Remove non-required locking from 'uvc_queue_next_buffer' > > > routine > > > > This patch removes the non-required spinlock acquire/release calls on > > > 'queue->irqlock' from 'uvc_queue_next_buffer' routine. > > > > > > This routine is called from 'video->encode' function (which > > translates > > > to either 'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in > > 'uvc_video.c'. > > > As, the 'video->encode' routines are called with 'queue->irqlock' > > > already held, so acquiring a 'queue->irqlock' again in > > > 'uvc_queue_next_buffer' routine causes a spin lock recursion. > > > > > > Signed-off-by: Bhupesh Sharma > > > Acked-by: Laurent Pinchart > > > > applied, thanks > > Not sure, if that can cause the merge conflict issue. > So now, should I send a clean patchset on top of your 3.5-rc1 branch to ensure > the entire new patchset for drivers/usb/gadget/*uvc* is pulled properly? Yes please, just give kernel.org about 20 minutes to sync all git servers. Just so you know, head on my gadget branch is: commit fbcaba0e3dcec8451cccdc1fa92fcddbde2bc3f2 Author: Bhupesh Sharma Date: Fri Jun 1 15:08:56 2012 +0530 usb: gadget: uvc: Add super-speed support to UVC webcam gadget This patch adds super-speed support to UVC webcam gadget. Also in this patch: - We add the configurability to pass bInterval, bMaxBurst, mult factors for video streaming endpoint (ISOC IN) through module parameters. - We use config_ep_by_speed helper routine to configure video streaming endpoint. Signed-off-b
RE: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
> -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, June 04, 2012 8:59 PM > To: Bhupesh SHARMA > Cc: ba...@ti.com; laurent.pinch...@ideasonboard.com; linux- > u...@vger.kernel.org; linux-media@vger.kernel.org; > gre...@linuxfoundation.org > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use > videobuf2 framework > > On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > > Hi Felipe, > > > > > -Original Message- > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Monday, June 04, 2012 8:44 PM > > > To: Bhupesh SHARMA > > > Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org; > > > ba...@ti.com; linux-media@vger.kernel.org; > > > gre...@linuxfoundation.org > > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to > > > use > > > videobuf2 framework > > > > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > > This patch reworks the videobuffer management logic present in > the > > > UVC > > > > webcam gadget and ports it to use the "more apt" videobuf2 > > > > framework for video buffer management. > > > > > > > > To support routing video data captured from a real V4L2 video > > > > capture device with a "zero copy" operation on videobuffers (as > > > > they pass > > > from > > > > the V4L2 domain to UVC domain via a user-space application), we > > > > need to support USER_PTR IO method at the UVC gadget side. > > > > > > > > So the V4L2 capture device driver can still continue to use MMAO > > > > IO method and now the user-space application can just pass a > > > > pointer to the video buffers being DeQueued from the V4L2 device > > > > side while Queueing them at the UVC gadget end. This ensures that > > > > we have a "zero-copy" design as the videobuffers pass from the > > > > V4L2 capture > > > device to the UVC gadget. > > > > > > > > Note that there will still be a need to apply UVC specific > payload > > > > headers on top of each UVC payload data, which will still require > > > > a copy operation to be performed in the 'encode' routines of the > > > > UVC > > > gadget. > > > > > > > > Signed-off-by: Bhupesh Sharma > > > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my > > > gadget branch which I will update in a while. > > > > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > > Should I now refresh my patches on top of your "v3.5-rc1" branch ? > > > > I am a bit confused on what is the latest gadget branch to be used > now. > > Thanks for helping out. > > The gadget branch is the branch called gadget on my kernel.org tree. > For some reason this didn't apply. Probably some patches on > drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. Possibly > because I was out for quite a while and asked Greg to help me out > during the merge window. > > Anyway, I just pushed gadget with a bunch of new patches and part of > your series. > Yes. I had sent two patches some time ago for drivers/usb/gadget/*uvc*. For one of them I received an *applied* message from you: > > usb: gadget/uvc: Remove non-required locking from 'uvc_queue_next_buffer' > > routine > > This patch removes the non-required spinlock acquire/release calls on > > 'queue->irqlock' from 'uvc_queue_next_buffer' routine. > > > > This routine is called from 'video->encode' function (which > translates > > to either 'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in > 'uvc_video.c'. > > As, the 'video->encode' routines are called with 'queue->irqlock' > > already held, so acquiring a 'queue->irqlock' again in > > 'uvc_queue_next_buffer' routine causes a spin lock recursion. > > > > Signed-off-by: Bhupesh Sharma > > Acked-by: Laurent Pinchart > > applied, thanks Not sure, if that can cause the merge conflict issue. So now, should I send a clean patchset on top of your 3.5-rc1 branch to ensure the entire new patchset for drivers/usb/gadget/*uvc* is pulled properly? Thanks, Bhupesh --- Begin Message --- On Fri, Mar 23, 2012 at 10:23:13PM +0530, Bhupesh Sharma wrote: > This patch removes the non-required spinlock acquire/release calls on > 'queue->irqlock' from 'uvc_queue_next_buffer' routine. > > This routine is called from 'video->encode' function (which translates to > either > 'uvc_video_encode_bulk' or 'uvc_video_encode_isoc') in 'uvc_video.c'. > As, the 'video->encode' routines are called with 'queue->irqlock' already > held, > so acquiring a 'queue->irqlock' again in 'uvc_queue_next_buffer' routine > causes > a spin lock recursion. > > Signed-off-by: Bhupesh Sharma > Acked-by: Laurent Pinchart applied, thanks -- balbi signature.asc Description: Digital signature --- End Message ---
Re: [RFC] Media controller entity information ioctl [was "Re: [patch] suggestion for media framework"]
On 04.06.2012 16:02, Laurent Pinchart wrote: > Hi Oleksiy, > > Thank you for the patch. > > [CC'ing linux-media] > > On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote: >> Hi Laurent, >> >> in attachment is a suggestion patch for media framework and a test >> program which use this patch. >> >> Suddenly we still didn't solved the problem with finding of XU. You >> know, the proper way to find them is guid (i do not need to explain this >> :)). Since uvc devices starting to have more and complicated XUs, media >> api is probably proper way to go - how you suggested. >> >> On the wiki of TexasInstruments i found some code examples, how they use >> this api. And it looks like there is some desing differences between >> OMPA drivers and UVC. It is easy to find proper entity name for omap >> devices just by: "(!strcmp(entity[index].name, "OMAP3 ISP CCDC"))". >> We can't do the same for UVC, current names are just "Extension %u". We >> can put guid instead, but it will looks ugly and not really informative. >> This is why i added new struct uvc_ext. >> >> If you do not agree with this patch, it will be good if you proved other >> solution. This problem need to be solved. > > The patch goes in the right direction, in that I think the media controller > API is the proper way to solve this problem. However, extending the > media_entity_desc structure with information about all possible kinds of > entities will not scale, especially given that an entity may need to expose > information related to multiple types (for instance an XU need to expose its > GUID, but also subdev-related information if it has a device node). > > I've been thinking about adding a new ioctl to the media controller API for > some time now, to report advanced static information about entities. > > The idea is that each entity would be allowed to report an arbitrary number > of > static items. Items would have a type (for which we would likely need some > kind of central registry, possible with driver-specific types), a length and > data. The items would be static (registered an initialization time) and > aggregated in a single buffer that would be read in one go through a new > ioctl. > > One important benefit of such an API would be to be able to report more than > one entity type per subdev using entity type items. Many entities serve > several purpose, for instance a sensor can integrate a flash controller. This > can't be reported with the current API, as subdevs have a single type. By > having several entity type items we could fix this issue. > > Details remain to be drafted, but I'd like a feedback on the general approach. Currently i can talk only about uvc :) Normally entity sub/type can be created by driver and device where documentation is available. For uvc it is not the case. If we get some comlicated uvc device with decumentation about XU, we will need userspace library to map all needed entities. But if you wont to make it static, created on driver init, then we will need some kind of plugin interface for uvcvideo (this sounds scary ;)) or remapable entities. Then one more question: for the case with uvcvideo + usb-audio, one of driver may reset complete device if it get some timeout or error. Make it sense to use media api to avoid it? For example uvcvideo set enitity state to busy, and if audio need to reset it and handler is not usb-audio for busy device, then it should notify handler... -- Regards, Oleksij -- 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: [PATCH] [media] soc-camera: Correct icl platform data assignment
Hi, Guennadi Yes, maybe you are right. I checked some i2c client drivers, they all changed it to: struct soc_camera_link *icl = soc_camera_i2c_to_link(client); We also can update our client driver, but could you please explain why do you change it? Thank you very much! Thanks Albert Wang 86-21-61092656 -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Monday, 04 June, 2012 20:29 To: Albert Wang Cc: linux-media@vger.kernel.org Subject: Re: [PATCH] [media] soc-camera: Correct icl platform data assignment Hi Albert On Mon, 4 Jun 2012, Albert Wang wrote: > This patch corrects icl platform data assignment > > from: > icl->board_info->platform_data = icl; > to: > icl->board_info->platform_data = icd; > > during init i2c device board info No, I don't think this is right. If it were right, all soc-camera systems would be broken for a couple of kernel versions. I think, you have to update your drivers... Thanks Guennadi > > Change-Id: Ia40a5ce96adbc5a1c3f3a90028e87a6fdbabc881 > Signed-off-by: Albert Wang > --- > drivers/media/video/soc_camera.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/soc_camera.c > b/drivers/media/video/soc_camera.c > index 0421bf9..cb8b8c7 100755 > --- a/drivers/media/video/soc_camera.c > +++ b/drivers/media/video/soc_camera.c > @@ -991,7 +991,7 @@ static int soc_camera_init_i2c(struct soc_camera_device > *icd, > goto ei2cga; > } > > - icl->board_info->platform_data = icl; > + icl->board_info->platform_data = icd; > > subdev = v4l2_i2c_new_subdev_board(&ici->v4l2_dev, adap, > icl->board_info, NULL); > -- > 1.7.0.4 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
On Mon, Jun 04, 2012 at 11:21:13PM +0800, Bhupesh SHARMA wrote: > Hi Felipe, > > > -Original Message- > > From: Felipe Balbi [mailto:ba...@ti.com] > > Sent: Monday, June 04, 2012 8:44 PM > > To: Bhupesh SHARMA > > Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org; > > ba...@ti.com; linux-media@vger.kernel.org; gre...@linuxfoundation.org > > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use > > videobuf2 framework > > > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > > This patch reworks the videobuffer management logic present in the > > UVC > > > webcam gadget and ports it to use the "more apt" videobuf2 framework > > > for video buffer management. > > > > > > To support routing video data captured from a real V4L2 video capture > > > device with a "zero copy" operation on videobuffers (as they pass > > from > > > the V4L2 domain to UVC domain via a user-space application), we need > > > to support USER_PTR IO method at the UVC gadget side. > > > > > > So the V4L2 capture device driver can still continue to use MMAO IO > > > method and now the user-space application can just pass a pointer to > > > the video buffers being DeQueued from the V4L2 device side while > > > Queueing them at the UVC gadget end. This ensures that we have a > > > "zero-copy" design as the videobuffers pass from the V4L2 capture > > device to the UVC gadget. > > > > > > Note that there will still be a need to apply UVC specific payload > > > headers on top of each UVC payload data, which will still require a > > > copy operation to be performed in the 'encode' routines of the UVC > > gadget. > > > > > > Signed-off-by: Bhupesh Sharma > > > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my > > gadget branch which I will update in a while. > > > > I rebased and submitted my changes on your "gadget-for-v3.5" tag. > Should I now refresh my patches on top of your "v3.5-rc1" branch ? > > I am a bit confused on what is the latest gadget branch to be used now. > Thanks for helping out. The gadget branch is the branch called gadget on my kernel.org tree. For some reason this didn't apply. Probably some patches on drivers/usb/gadget/*uvc* went into v3.5 without my knowledge. Possibly because I was out for quite a while and asked Greg to help me out during the merge window. Anyway, I just pushed gadget with a bunch of new patches and part of your series. -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > This patch reworks the videobuffer management logic present in the UVC > webcam gadget and ports it to use the "more apt" videobuf2 framework for > video buffer management. > > To support routing video data captured from a real V4L2 video capture > device with a "zero copy" operation on videobuffers (as they pass from the > V4L2 > domain to UVC domain via a user-space application), we need to support > USER_PTR > IO method at the UVC gadget side. > > So the V4L2 capture device driver can still continue to use MMAO IO method > and now the user-space application can just pass a pointer to the video > buffers > being DeQueued from the V4L2 device side while Queueing them at the UVC gadget > end. This ensures that we have a "zero-copy" design as the videobuffers pass > from the V4L2 capture device to the UVC gadget. > > Note that there will still be a need to apply UVC specific payload headers > on top of each UVC payload data, which will still require a copy operation > to be performed in the 'encode' routines of the UVC gadget. > > Signed-off-by: Bhupesh Sharma this patch doesn't apply. Please refresh on top of v3.5-rc1 or my gadget branch which I will update in a while. -- balbi signature.asc Description: Digital signature
RE: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Felipe, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, June 04, 2012 8:44 PM > To: Bhupesh SHARMA > Cc: laurent.pinch...@ideasonboard.com; linux-...@vger.kernel.org; > ba...@ti.com; linux-media@vger.kernel.org; gre...@linuxfoundation.org > Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use > videobuf2 framework > > On Fri, Jun 01, 2012 at 03:08:57PM +0530, Bhupesh Sharma wrote: > > This patch reworks the videobuffer management logic present in the > UVC > > webcam gadget and ports it to use the "more apt" videobuf2 framework > > for video buffer management. > > > > To support routing video data captured from a real V4L2 video capture > > device with a "zero copy" operation on videobuffers (as they pass > from > > the V4L2 domain to UVC domain via a user-space application), we need > > to support USER_PTR IO method at the UVC gadget side. > > > > So the V4L2 capture device driver can still continue to use MMAO IO > > method and now the user-space application can just pass a pointer to > > the video buffers being DeQueued from the V4L2 device side while > > Queueing them at the UVC gadget end. This ensures that we have a > > "zero-copy" design as the videobuffers pass from the V4L2 capture > device to the UVC gadget. > > > > Note that there will still be a need to apply UVC specific payload > > headers on top of each UVC payload data, which will still require a > > copy operation to be performed in the 'encode' routines of the UVC > gadget. > > > > Signed-off-by: Bhupesh Sharma > > this patch doesn't apply. Please refresh on top of v3.5-rc1 or my > gadget branch which I will update in a while. > I rebased and submitted my changes on your "gadget-for-v3.5" tag. Should I now refresh my patches on top of your "v3.5-rc1" branch ? I am a bit confused on what is the latest gadget branch to be used now. Thanks for helping out. Regards, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Media controller entity information ioctl [was "Re: [patch] suggestion for media framework"]
On Mon June 4 2012 16:02:12 Laurent Pinchart wrote: > Hi Oleksiy, > > Thank you for the patch. > > [CC'ing linux-media] > > On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote: > > Hi Laurent, > > > > in attachment is a suggestion patch for media framework and a test > > program which use this patch. > > > > Suddenly we still didn't solved the problem with finding of XU. You > > know, the proper way to find them is guid (i do not need to explain this > > :)). Since uvc devices starting to have more and complicated XUs, media > > api is probably proper way to go - how you suggested. > > > > On the wiki of TexasInstruments i found some code examples, how they use > > this api. And it looks like there is some desing differences between > > OMPA drivers and UVC. It is easy to find proper entity name for omap > > devices just by: "(!strcmp(entity[index].name, "OMAP3 ISP CCDC"))". > > We can't do the same for UVC, current names are just "Extension %u". We > > can put guid instead, but it will looks ugly and not really informative. > > This is why i added new struct uvc_ext. > > > > If you do not agree with this patch, it will be good if you proved other > > solution. This problem need to be solved. > > The patch goes in the right direction, in that I think the media controller > API is the proper way to solve this problem. However, extending the > media_entity_desc structure with information about all possible kinds of > entities will not scale, especially given that an entity may need to expose > information related to multiple types (for instance an XU need to expose its > GUID, but also subdev-related information if it has a device node). > > I've been thinking about adding a new ioctl to the media controller API for > some time now, to report advanced static information about entities. > > The idea is that each entity would be allowed to report an arbitrary number > of > static items. Items would have a type (for which we would likely need some > kind of central registry, possible with driver-specific types), a length and > data. The items would be static (registered an initialization time) and > aggregated in a single buffer that would be read in one go through a new > ioctl. And since it is static the media_entity_desc struct can tell the caller how many of these items there are, and use that information to retrieve them. > One important benefit of such an API would be to be able to report more than > one entity type per subdev using entity type items. Many entities serve > several purpose, for instance a sensor can integrate a flash controller. This > can't be reported with the current API, as subdevs have a single type. By > having several entity type items we could fix this issue. > > Details remain to be drafted, but I'd like a feedback on the general approach. Sound good. We discussed this before, and I agree that these seems to be the right approach. 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
[RFC] Media controller entity information ioctl [was "Re: [patch] suggestion for media framework"]
Hi Oleksiy, Thank you for the patch. [CC'ing linux-media] On Sunday 03 June 2012 19:17:06 Oleksij Rempel wrote: > Hi Laurent, > > in attachment is a suggestion patch for media framework and a test > program which use this patch. > > Suddenly we still didn't solved the problem with finding of XU. You > know, the proper way to find them is guid (i do not need to explain this > :)). Since uvc devices starting to have more and complicated XUs, media > api is probably proper way to go - how you suggested. > > On the wiki of TexasInstruments i found some code examples, how they use > this api. And it looks like there is some desing differences between > OMPA drivers and UVC. It is easy to find proper entity name for omap > devices just by: "(!strcmp(entity[index].name, "OMAP3 ISP CCDC"))". > We can't do the same for UVC, current names are just "Extension %u". We > can put guid instead, but it will looks ugly and not really informative. > This is why i added new struct uvc_ext. > > If you do not agree with this patch, it will be good if you proved other > solution. This problem need to be solved. The patch goes in the right direction, in that I think the media controller API is the proper way to solve this problem. However, extending the media_entity_desc structure with information about all possible kinds of entities will not scale, especially given that an entity may need to expose information related to multiple types (for instance an XU need to expose its GUID, but also subdev-related information if it has a device node). I've been thinking about adding a new ioctl to the media controller API for some time now, to report advanced static information about entities. The idea is that each entity would be allowed to report an arbitrary number of static items. Items would have a type (for which we would likely need some kind of central registry, possible with driver-specific types), a length and data. The items would be static (registered an initialization time) and aggregated in a single buffer that would be read in one go through a new ioctl. One important benefit of such an API would be to be able to report more than one entity type per subdev using entity type items. Many entities serve several purpose, for instance a sensor can integrate a flash controller. This can't be reported with the current API, as subdevs have a single type. By having several entity type items we could fix this issue. Details remain to be drafted, but I'd like a feedback on the general approach. -- 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: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
On 12-06-04 09:35 AM, Devin Heitmueller wrote: > > The 950q doesn't use the dvb-usb framework (nor does it load the > firmware at init). Whatever is going on there is completely unrelated > to what Antti is debugging. Ahhh. Pity. I was almost giddy there for a second. :-/ Cheers, b. signature.asc Description: OpenPGP digital signature
Re: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
On Mon, Jun 4, 2012 at 9:32 AM, Brian J. Murrell wrote: > On 12-06-03 05:01 PM, Antti Palosaari wrote: >> >> That firmware downloading patch is done top of my new dvb-usb >> development tree. I have converted very limited set of drivers for that >> tree, af9015, au6610, ec168 and anysee (and those are only on my local >> hard disk). I tried to backport patch for the current dvb-usb but I ran >> many problems and gave up. Looks like it is almost impossible to convert >> old dvb-usb without big changes... >> >> So what driver you are using? > > I'm using the hvr-950q per > https://bugzilla.kernel.org/show_bug.cgi?id=43145 and > https://bugzilla.kernel.org/show_bug.cgi?id=43146. > >> It is possible I can convert your driver >> too and then it is possible to test. > > Great. Ideally it would be great to get this backported and applied to > the linux 3.2.0 release stream. The 950q doesn't use the dvb-usb framework (nor does it load the firmware at init). Whatever is going on there is completely unrelated to what Antti is debugging. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- 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: [PATCH v2 01/10] string: introduce memweight
On Mon 04-06-12 20:46:14, Akinobu Mita wrote:
> 2012/6/4 Jan Kara :
> > On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
> >> memweight() is the function that counts the total number of bits set
> >> in memory area. Unlike bitmap_weight(), memweight() takes pointer
> >> and size in bytes to specify a memory area which does not need to be
> >> aligned to long-word boundary.
> >>
> >> Signed-off-by: Akinobu Mita
> >> Cc: Anders Larsen
> >> Cc: Alasdair Kergon
> >> Cc: dm-de...@redhat.com
> >> Cc: linux-fsde...@vger.kernel.org
> >> Cc: Laurent Pinchart
> >> Cc: linux-media@vger.kernel.org
> >> Cc: Mark Fasheh
> >> Cc: Joel Becker
> >> Cc: ocfs2-de...@oss.oracle.com
> >> Cc: Jan Kara
> >> Cc: linux-e...@vger.kernel.org
> >> Cc: Andrew Morton
> >> Cc: Andreas Dilger
> >> Cc: "Theodore Ts'o"
> >> Cc: Matthew Wilcox
> >> ---
> >>
> >> v2: simplify memweight(), adviced by Jan Kara
> >>
> >> include/linux/string.h | 3 +++
> >> lib/string.c | 32
> >> 2 files changed, 35 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/linux/string.h b/include/linux/string.h
> >> index e033564..ffe0442 100644
> >> --- a/include/linux/string.h
> >> +++ b/include/linux/string.h
> >> @@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const
> >> char *prefix)
> >> return strncmp(str, prefix, strlen(prefix)) == 0;
> >> }
> >> #endif
> >> +
> >> +extern size_t memweight(const void *ptr, size_t bytes);
> >> +
> >> #endif /* _LINUX_STRING_H_ */
> >> diff --git a/lib/string.c b/lib/string.c
> >> index e5878de..bf4d5a8 100644
> >> --- a/lib/string.c
> >> +++ b/lib/string.c
> >> @@ -26,6 +26,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #ifndef __HAVE_ARCH_STRNICMP
> >> /**
> >> @@ -824,3 +825,34 @@ void *memchr_inv(const void *start, int c, size_t
> >> bytes)
> >> return check_bytes8(start, value, bytes % 8);
> >> }
> >> EXPORT_SYMBOL(memchr_inv);
> >> +
> >> +/**
> >> + * memweight - count the total number of bits set in memory area
> >> + * @ptr: pointer to the start of the area
> >> + * @bytes: the size of the area
> >> + */
> >> +size_t memweight(const void *ptr, size_t bytes)
> >> +{
> >> + size_t w = 0;
> >> + size_t longs;
> >> + const unsigned char *bitmap = ptr;
> >> +
> >> + for (; bytes > 0 && ((unsigned long)bitmap) % sizeof(long);
> >> + bytes--, bitmap++)
> >> + w += hweight8(*bitmap);
> >> +
> >> + longs = bytes / sizeof(long);
> >> + if (longs) {
> >> + BUG_ON(longs >= INT_MAX / BITS_PER_LONG);
> >> + w += bitmap_weight((unsigned long *)bitmap,
> >> + longs * BITS_PER_LONG);
> >> + bytes -= longs * sizeof(long);
> >> + bitmap += longs * sizeof(long);
> >> + }
> >> +
> >> + for (; bytes > 0; bytes--, bitmap++)
> >> + w += hweight8(*bitmap);
> > Looking at bitmap_weight() it seems this last loop is not needed. Just
> > pass to bitmap_weight() bytes*BITS_PER_BYTE. Also generally this function
> > doesn't seem necessary at all at least for ext2 & ext3 (sorry for not
> > noticing this earlier...).
>
> This last loop is necessary for big-endian architecture.
> if bytes % sizeof(long) != 0, bitmap_weight() counts one-bits in wrong
> byte-field
> of the last long word.
Ah, right. OK. Add this to the comment before the loop please. You save
yourself some explanations :)
Honza
--
Jan Kara
SUSE Labs, CR
--
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: Fwd: [Bug 827538] DVB USB device firmware requested in module_init()
On 12-06-03 05:01 PM, Antti Palosaari wrote: > > That firmware downloading patch is done top of my new dvb-usb > development tree. I have converted very limited set of drivers for that > tree, af9015, au6610, ec168 and anysee (and those are only on my local > hard disk). I tried to backport patch for the current dvb-usb but I ran > many problems and gave up. Looks like it is almost impossible to convert > old dvb-usb without big changes... > > So what driver you are using? I'm using the hvr-950q per https://bugzilla.kernel.org/show_bug.cgi?id=43145 and https://bugzilla.kernel.org/show_bug.cgi?id=43146. > It is possible I can convert your driver > too and then it is possible to test. Great. Ideally it would be great to get this backported and applied to the linux 3.2.0 release stream. Cheers, b. signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] s5p-mfc: added encoder support for end of stream handling
On Wed, 2012-05-23 at 14:28 +0200, Hans Verkuil wrote: > On Wed 23 May 2012 13:20:03 Andrzej Hajda wrote: > > On Wed, 2012-05-23 at 09:43 +0200, Hans Verkuil wrote: > > > Hi Andrzej! > > > > > > Thanks for the patch, but I do have two questions: > > > > > > On Tue 22 May 2012 17:33:53 Andrzej Hajda wrote: > > > > Those patches add end of stream handling for s5p-mfc encoder. > > > > > > > > The first patch was sent already to the list as RFC, but the discussion > > > > ended > > > > without any decision. > > > > This patch adds new v4l2_buffer flag V4L2_BUF_FLAG_EOS. Below short > > > > description of this change. > > > > > > > > s5p_mfc is a mem-to-mem MPEG/H263/H264 encoder and it requires that the > > > > last > > > > incoming frame must be processed differently, it means the information > > > > about > > > > the end of the stream driver should receive NOT LATER than the last > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer. Common practice > > > > of sending empty buffer to indicate end-of-stream do not work in such > > > > case. > > > > Setting V4L2_BUF_FLAG_EOS flag for the last > > > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE > > > > buffer seems to be the most straightforward solution here. > > > > > > > > V4L2_BUF_FLAG_EOS flag should be used by application if driver requires > > > > it > > > > > > How will the application know that? > > > > Application can always set this flag, it will be ignored by drivers not > > requiring it. > > That's going to make it very hard to write generic applications: people will > always forget to set that flag, unless they happen to using your hardware. > > > I see some drawback of this solution - application should know if the > > frame enqueued to the driver is the last one. If the application > > receives frames to encode form an external source (for example via pipe) > > it often does not know if the frame it received is the last one. So to > > be able to properly queue frame to the driver it should wait with frame > > queuing until it knows there is next frame or end-of-stream is reached, > > in such situation it will properly set flag before queuing. > > > > Alternative to "V4L2_BUF_FLAG_EOS" solution is to implement "wait for > > next frame" logic directly into the driver. In such case application can > > use empty buffer to signal the end of the stream. Driver waits with > > frame processing if there are at least two buffers in output queue. Then > > it checks if the second buffer is empty if not it process the first > > buffer as a normal frame and repeats procedure, if yes it process the > > first buffer as the last frame and releases second buffer. > > In the current V4L2 API the last output frame is reached when: > > 1) the filehandle is closed > 2) VIDIOC_STREAMOFF is called > 3) VIDIOC_ENCODER_CMD is called with V4L2_ENC_CMD_STOP. > > The latter is currently only used by MPEG encoders, but it might be an idea > to consider it for your hardware as well. Perhaps a flag like > 'stop_after_next_frame' > is needed. It seemed to me less straightforward - EOS is sent before the last frame - but I can implement it this way of course. > > How are cases 1 and 2 handled today? > As I lurked into the driver's code it seems it behaves in standard way - driver waits for device to finish current operation if there is any, next it releases all buffers. > And what happens if the app sets the EOS flag, and then later queues another > buffer without that flag. Is that frame accepted/rejected/ignored? I have not take care of this situation. The simplest solution is to reject frames, application in that case should reopen device to encode next stream if necessary. Other solution I see is to allow queue output frames but do not process them by device until device finish producing encoded frames, it would require device reinitialization. > > I'm trying to understand how the current implementation behaves in corner > cases > like those. > > > The drawback of this solution is that it wastes resources/space > > (additional buffer) and time (delayed encoding). > > > > I am still hesitating which solution is better, any advices? > > > > > > > > and it should be set only on V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffers. > > > > > > Why only for this type? > > > > I wanted to say only for output buffers not just output multi-plane. And > > why not capture? Explanation below. > > Capture buffers are filled by driver, so only drivers could set this > > flag. Some devices provides information about the end of the stream > > together with the last frame, but some devices provides this info later > > (for example s5p-mfc :) ). In the latter case to properly flag the > > capture buffer driver should wait for next available frame. Simpler > > solution is to use current solution with sending empty buffer to signal > > the end of the stream. > > I don't believe this is documented anywhere. Wouldn't it be better to send > a V4L2_EVENT_EOS event? That's documented
Re: [PATCH] [media] soc-camera: Correct icl platform data assignment
Hi Albert On Mon, 4 Jun 2012, Albert Wang wrote: > This patch corrects icl platform data assignment > > from: > icl->board_info->platform_data = icl; > to: > icl->board_info->platform_data = icd; > > during init i2c device board info No, I don't think this is right. If it were right, all soc-camera systems would be broken for a couple of kernel versions. I think, you have to update your drivers... Thanks Guennadi > > Change-Id: Ia40a5ce96adbc5a1c3f3a90028e87a6fdbabc881 > Signed-off-by: Albert Wang > --- > drivers/media/video/soc_camera.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/soc_camera.c > b/drivers/media/video/soc_camera.c > index 0421bf9..cb8b8c7 100755 > --- a/drivers/media/video/soc_camera.c > +++ b/drivers/media/video/soc_camera.c > @@ -991,7 +991,7 @@ static int soc_camera_init_i2c(struct soc_camera_device > *icd, > goto ei2cga; > } > > - icl->board_info->platform_data = icl; > + icl->board_info->platform_data = icd; > > subdev = v4l2_i2c_new_subdev_board(&ici->v4l2_dev, adap, > icl->board_info, NULL); > -- > 1.7.0.4 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCH v2 01/10] string: introduce memweight
2012/6/4 Jan Kara :
> On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
>> memweight() is the function that counts the total number of bits set
>> in memory area. Unlike bitmap_weight(), memweight() takes pointer
>> and size in bytes to specify a memory area which does not need to be
>> aligned to long-word boundary.
>>
>> Signed-off-by: Akinobu Mita
>> Cc: Anders Larsen
>> Cc: Alasdair Kergon
>> Cc: dm-de...@redhat.com
>> Cc: linux-fsde...@vger.kernel.org
>> Cc: Laurent Pinchart
>> Cc: linux-media@vger.kernel.org
>> Cc: Mark Fasheh
>> Cc: Joel Becker
>> Cc: ocfs2-de...@oss.oracle.com
>> Cc: Jan Kara
>> Cc: linux-e...@vger.kernel.org
>> Cc: Andrew Morton
>> Cc: Andreas Dilger
>> Cc: "Theodore Ts'o"
>> Cc: Matthew Wilcox
>> ---
>>
>> v2: simplify memweight(), adviced by Jan Kara
>>
>> include/linux/string.h | 3 +++
>> lib/string.c | 32
>> 2 files changed, 35 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/string.h b/include/linux/string.h
>> index e033564..ffe0442 100644
>> --- a/include/linux/string.h
>> +++ b/include/linux/string.h
>> @@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const char
>> *prefix)
>> return strncmp(str, prefix, strlen(prefix)) == 0;
>> }
>> #endif
>> +
>> +extern size_t memweight(const void *ptr, size_t bytes);
>> +
>> #endif /* _LINUX_STRING_H_ */
>> diff --git a/lib/string.c b/lib/string.c
>> index e5878de..bf4d5a8 100644
>> --- a/lib/string.c
>> +++ b/lib/string.c
>> @@ -26,6 +26,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #ifndef __HAVE_ARCH_STRNICMP
>> /**
>> @@ -824,3 +825,34 @@ void *memchr_inv(const void *start, int c, size_t bytes)
>> return check_bytes8(start, value, bytes % 8);
>> }
>> EXPORT_SYMBOL(memchr_inv);
>> +
>> +/**
>> + * memweight - count the total number of bits set in memory area
>> + * @ptr: pointer to the start of the area
>> + * @bytes: the size of the area
>> + */
>> +size_t memweight(const void *ptr, size_t bytes)
>> +{
>> + size_t w = 0;
>> + size_t longs;
>> + const unsigned char *bitmap = ptr;
>> +
>> + for (; bytes > 0 && ((unsigned long)bitmap) % sizeof(long);
>> + bytes--, bitmap++)
>> + w += hweight8(*bitmap);
>> +
>> + longs = bytes / sizeof(long);
>> + if (longs) {
>> + BUG_ON(longs >= INT_MAX / BITS_PER_LONG);
>> + w += bitmap_weight((unsigned long *)bitmap,
>> + longs * BITS_PER_LONG);
>> + bytes -= longs * sizeof(long);
>> + bitmap += longs * sizeof(long);
>> + }
>> +
>> + for (; bytes > 0; bytes--, bitmap++)
>> + w += hweight8(*bitmap);
> Looking at bitmap_weight() it seems this last loop is not needed. Just
> pass to bitmap_weight() bytes*BITS_PER_BYTE. Also generally this function
> doesn't seem necessary at all at least for ext2 & ext3 (sorry for not
> noticing this earlier...).
This last loop is necessary for big-endian architecture.
if bytes % sizeof(long) != 0, bitmap_weight() counts one-bits in wrong
byte-field
of the last long word.
--
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
Doing a new upstream / linuxtv.org xawtv3 release?
Hi All, I've been doing a lot of work on xawtv3 lately, mostly on the radio app but also some on xawtv itself. I'm no done and IMHO it would be good to do a new upstream release to get all those changes out there. So any comments / suggestions? Note "go for it" also is a valid comment :) 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: [PATCH v2 01/10] string: introduce memweight
On Sat 02-06-12 22:40:07, Akinobu Mita wrote:
> memweight() is the function that counts the total number of bits set
> in memory area. Unlike bitmap_weight(), memweight() takes pointer
> and size in bytes to specify a memory area which does not need to be
> aligned to long-word boundary.
>
> Signed-off-by: Akinobu Mita
> Cc: Anders Larsen
> Cc: Alasdair Kergon
> Cc: dm-de...@redhat.com
> Cc: linux-fsde...@vger.kernel.org
> Cc: Laurent Pinchart
> Cc: linux-media@vger.kernel.org
> Cc: Mark Fasheh
> Cc: Joel Becker
> Cc: ocfs2-de...@oss.oracle.com
> Cc: Jan Kara
> Cc: linux-e...@vger.kernel.org
> Cc: Andrew Morton
> Cc: Andreas Dilger
> Cc: "Theodore Ts'o"
> Cc: Matthew Wilcox
> ---
>
> v2: simplify memweight(), adviced by Jan Kara
>
> include/linux/string.h |3 +++
> lib/string.c | 32
> 2 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/string.h b/include/linux/string.h
> index e033564..ffe0442 100644
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -145,4 +145,7 @@ static inline bool strstarts(const char *str, const char
> *prefix)
> return strncmp(str, prefix, strlen(prefix)) == 0;
> }
> #endif
> +
> +extern size_t memweight(const void *ptr, size_t bytes);
> +
> #endif /* _LINUX_STRING_H_ */
> diff --git a/lib/string.c b/lib/string.c
> index e5878de..bf4d5a8 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #ifndef __HAVE_ARCH_STRNICMP
> /**
> @@ -824,3 +825,34 @@ void *memchr_inv(const void *start, int c, size_t bytes)
> return check_bytes8(start, value, bytes % 8);
> }
> EXPORT_SYMBOL(memchr_inv);
> +
> +/**
> + * memweight - count the total number of bits set in memory area
> + * @ptr: pointer to the start of the area
> + * @bytes: the size of the area
> + */
> +size_t memweight(const void *ptr, size_t bytes)
> +{
> + size_t w = 0;
> + size_t longs;
> + const unsigned char *bitmap = ptr;
> +
> + for (; bytes > 0 && ((unsigned long)bitmap) % sizeof(long);
> + bytes--, bitmap++)
> + w += hweight8(*bitmap);
> +
> + longs = bytes / sizeof(long);
> + if (longs) {
> + BUG_ON(longs >= INT_MAX / BITS_PER_LONG);
> + w += bitmap_weight((unsigned long *)bitmap,
> + longs * BITS_PER_LONG);
> + bytes -= longs * sizeof(long);
> + bitmap += longs * sizeof(long);
> + }
> +
> + for (; bytes > 0; bytes--, bitmap++)
> + w += hweight8(*bitmap);
Looking at bitmap_weight() it seems this last loop is not needed. Just
pass to bitmap_weight() bytes*BITS_PER_BYTE. Also generally this function
doesn't seem necessary at all at least for ext2 & ext3 (sorry for not
noticing this earlier...).
Honza
--
Jan Kara
SUSE Labs, CR
--
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
[PATCH] [media] soc-camera: Correct icl platform data assignment
This patch corrects icl platform data assignment from: icl->board_info->platform_data = icl; to: icl->board_info->platform_data = icd; during init i2c device board info Change-Id: Ia40a5ce96adbc5a1c3f3a90028e87a6fdbabc881 Signed-off-by: Albert Wang --- drivers/media/video/soc_camera.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index 0421bf9..cb8b8c7 100755 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -991,7 +991,7 @@ static int soc_camera_init_i2c(struct soc_camera_device *icd, goto ei2cga; } - icl->board_info->platform_data = icl; + icl->board_info->platform_data = icd; subdev = v4l2_i2c_new_subdev_board(&ici->v4l2_dev, adap, icl->board_info, NULL); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2] media: Add stk1160 new driver
On Sun June 3 2012 23:44:03 Ezequiel Garcia wrote: > Hans, > > On Sun, Jun 3, 2012 at 7:33 AM, Hans Verkuil wrote: > > > > Thanks. I've fixed several things reported by v4l2-compliance (see my patch > > below), but you are using an older v4l2-compliance version. You should clone > > and compile the v4l-utils.git repository yourself, rather than using a > > distro > > provided version (which I think is what you are doing now). > > > > Can you apply my patch on yours and run the latest v4l2-compliance again? > > I applied your patch, updated v4l2-compliance and here is the output: > > --- > $ v4l2-compliance -d /dev/video1 > Driver Info: > Driver name : stk1160 > Card type : stk1160 > Bus info : usb-:00:13.2-1 > Driver version: 3.4.0 > Capabilities : 0x8501 > Video Capture > Read/Write > Streaming > Device Capabilities > Device Caps : 0x0501 > Video Capture > Read/Write > Streaming > > Compliance test for device /dev/video1 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G_CHIP_IDENT: Not Supported > test VIDIOC_DBG_G/S_REGISTER: Not Supported > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER: Not Supported > test VIDIOC_G/S_FREQUENCY: Not Supported > test VIDIOC_S_HW_FREQ_SEEK: Not Supported > test VIDIOC_ENUMAUDIO: Not Supported > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: Not Supported > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: Not Supported > test VIDIOC_G/S_FREQUENCY: Not Supported > test VIDIOC_ENUMAUDOUT: Not Supported > test VIDIOC_G/S/ENUMOUTPUT: Not Supported > test VIDIOC_G/S_AUDOUT: Not Supported > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Control ioctls: > test VIDIOC_QUERYCTRL/MENU: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: Not Supported > Standard Controls: 7 Private Controls: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK > test VIDIOC_ENUM/G/S/QUERY_DV_PRESETS: Not Supported > test VIDIOC_G/S_DV_TIMINGS: Not Supported > > Format ioctls: > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: Not Supported > test VIDIOC_G_FBUF: Not Supported > test VIDIOC_G_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: Not Supported > Total: 31 Succeeded: 31 Failed: 0 Warnings: 0 > --- > > None failed! :-) Nice! > Would you care to explain me this change in your patch? > + set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags); See Documentation/video4linux/v4l2-framework.txt: "flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct v4l2_fh. Eventually this flag will disappear once all drivers use the core priority handling. But for now it has to be set explicitly." Regards, Hans > > I guess I can consider the video part as working (at least with a > basic set of features). > I'll be working on alsa and support for several inputs now. > > Thanks for reviewing! > Ezequiel. > -- 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
