Re: [PATCHv10 08/26] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

[Marek Szyprowski]

Hello,

On 10/26/2012 6:24 PM, Pawel Osciak wrote:

Hi Tomasz,

On Wed, Oct 10, 2012 at 7:46 AM, Tomasz Stanislawski
 wrote:

This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.



Perhaps I'm missing something, but I don't understand the purpose of
this patch. If the device can do DMA SG, why use videobuf2-dma-contig
and not videobuf2-dma-sg?


This patch is for devices which doesn't do DMA SG, but might be behind 
IOMMU. In such case one can call dma_map_sg() with scatterlist of 
individual pages gathered from user pointer (anonymous memory of the 
process) which in turn will be mapped into contiguous dma adress space 
(dma_map_sg() returns only one chunk in such case). This is not very 
intuitive, but it was best way to fit such case into existing 
dma-mapping design.



What would be the difference design-wise
between them if this patch is merged?


Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

--
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 00/23] em28xx: add support fur USB bulk transfers

[Mauro Carvalho Chehab]

Em Tue, 30 Oct 2012 01:00:12 -0200
Mauro Carvalho Chehab  escreveu:

> Em Mon, 29 Oct 2012 23:14:55 +0200
> Frank Schäfer  escreveu:
> 
> > Am 29.10.2012 22:03, schrieb Mauro Carvalho Chehab:
> > > Em Mon, 29 Oct 2012 17:33:12 +0200
> > > Frank Schäfer  escreveu:
> > >
> > >> Am 28.10.2012 21:57, schrieb Mauro Carvalho Chehab:
> > >>> Em Sun, 21 Oct 2012 19:52:05 +0300
> > >>> Frank Schäfer  escreveu:
> > >>>
> >  This patch series adds support for USB bulk transfers to the em28xx 
> >  driver.
> > 
> >  Patch 1 is a bugfix for the image data processing with non-interlaced 
> >  devices (webcams)
> >  that should be considered for stable (see commit message).
> > 
> >  Patches 2-21 extend the driver to support USB bulk transfers.
> >  USB endpoint mapping had to be extended and is a bit tricky.
> >  It might still not be sufficient to handle ALL isoc/bulk endpoints of 
> >  ALL existing devices,
> >  but it should work with the devices we have seen so far and (most 
> >  important !) 
> >  preserves backwards compatibility to the current driver behavior.
> >  Isoc endpoints/transfers are preffered by default, patch 21 adds a 
> >  module parameter to change this behavior.
> > 
> >  The last two patches are follow-up patches not really related to USB 
> >  tranfers.
> >  Patch 22 reduces the code size in em28xx-video by merging the two URB 
> >  data processing functions 
> >  and patch 23 enables VBI-support for em2840-devices.
> > 
> >  Please note that I could test the changes with an analog 
> >  non-interlaced non-VBI device only !
> >  So further tests with DVB/interlaced/VBI devices are strongly 
> >  recommended !
> > >>> Did a quick test here with all applied, with analog TV with xawtv and 
> > >>> tvtime. 
> > >>> Didn't work.
> > >> Ok, thanks for testing.
> > >>
> > >>> I'll need to postpone it, until I have more time to double check it and 
> > >>> bisect.
> > >> I would also need further informations about the test you've made (did
> > >> you enable bulk ?) and the device you used (supports VBI ?).
> > > I used a WinTV HVR-950/980. Logs enclosed.
> > >
> > > Regards,
> > > Mauro
> > 
> > Thanks.
> > Did you load the module with prefer_bulk=1 ?
> 
> No.
> 
> > You just started xawtv/tvtime but got no picture, right ?
> 
> Yes. I tested also v4l2grab. No frames got returned there.
> 
> > 
> > There is nothing unusual in the log, except...
> > 
> > ...
> > > [ 8412.464698] xc2028 3-0061: Can't find firmware for type=BASE INIT1 
> > > F8MHZ MTS (4007), id .
> > ...
> > > [ 8412.464709] xc2028 3-0061: Can't find firmware for type=BASE INIT1 MTS 
> > > (4005), id .
> > ...
> 
> Those are normal. AFAIKT, only firmwares < version 2.0 had init broken into
> INIT0 and INIT1.
> 
> > > [ 8412.490804] xc2028 3-0061: Can't find firmware for type=MTS SCODE 
> > > (2004), id 00010007.
> 
> This is ok, as another similar SCODE firmware got loaded.
> 
> > 
> > and
> > 
> > ...
> > > [ 8454.966006] xc2028 3-0061: xc2028_get_reg 0002 called
> > > [ 8454.990113] xc2028 3-0061: i2c input error: rc = -19 (should be 2)
> > > [ 8454.996282] xc2028 3-0061: xc2028_signal called
> > > [ 8454.997656] xc2028 3-0061: xc2028_get_reg 0002 called
> > > [ 8455.021846] xc2028 3-0061: i2c input error: rc = -19 (should be 2)
> 
> Those are weird. In any case, as far as I remember, even if xc3028 is bad 
> tuned,
> em28xx should be outputing some data. I suspect, however, that those errors
> maybe because the em28xx chip has died already.
> 
> > 
> > Are these errors normal ?
> > Are you sure the device is working properly without my patches ?
> 
> Yes. See below.
> 
> > 
> > You could try to load the em28xx module with usb_debug=1.
> 
> I'll post it on a separate email.
> 

Did a git bisect. The last patch where the bug doesn't occur is this 
changeset:
em28xx: add module parameter for selection of the preferred USB 
transfer type

That means that this changeset broke it:

em28xx: use common urb data copying function for vbi and non-vbi devices

I didn't test them with my Silvercrest webcam yet.

I hope that helps.

Regards,
Mauro

PS.: Logs of the latest working driver is enclosed.


[ 4658.112071] media: Linux media interface: v0.10
[ 4658.118615] Linux video capture interface: v2.00
[ 4658.123229] WARNING: You are using an experimental version of the media 
stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
d259aec2578fe66c43ae89ef65735fa7b70fa948 [media] em28xx: add module 
parameter for selection of the preferred USB transfer type
2c930ac7e1aa0c8181d5d283e4cb5de69b8121d5 [media] em28xx: improve USB 
endpoint logic, also use bulk transfers
6b43cf6a235d564

Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 23:14:55 +0200
Frank Schäfer  escreveu:

> Am 29.10.2012 22:03, schrieb Mauro Carvalho Chehab:
> > Em Mon, 29 Oct 2012 17:33:12 +0200
> > Frank Schäfer  escreveu:
> >
> >> Am 28.10.2012 21:57, schrieb Mauro Carvalho Chehab:
> >>> Em Sun, 21 Oct 2012 19:52:05 +0300
> >>> Frank Schäfer  escreveu:
> >>>
>  This patch series adds support for USB bulk transfers to the em28xx 
>  driver.
> 
>  Patch 1 is a bugfix for the image data processing with non-interlaced 
>  devices (webcams)
>  that should be considered for stable (see commit message).
> 
>  Patches 2-21 extend the driver to support USB bulk transfers.
>  USB endpoint mapping had to be extended and is a bit tricky.
>  It might still not be sufficient to handle ALL isoc/bulk endpoints of 
>  ALL existing devices,
>  but it should work with the devices we have seen so far and (most 
>  important !) 
>  preserves backwards compatibility to the current driver behavior.
>  Isoc endpoints/transfers are preffered by default, patch 21 adds a 
>  module parameter to change this behavior.
> 
>  The last two patches are follow-up patches not really related to USB 
>  tranfers.
>  Patch 22 reduces the code size in em28xx-video by merging the two URB 
>  data processing functions 
>  and patch 23 enables VBI-support for em2840-devices.
> 
>  Please note that I could test the changes with an analog non-interlaced 
>  non-VBI device only !
>  So further tests with DVB/interlaced/VBI devices are strongly 
>  recommended !
> >>> Did a quick test here with all applied, with analog TV with xawtv and 
> >>> tvtime. 
> >>> Didn't work.
> >> Ok, thanks for testing.
> >>
> >>> I'll need to postpone it, until I have more time to double check it and 
> >>> bisect.
> >> I would also need further informations about the test you've made (did
> >> you enable bulk ?) and the device you used (supports VBI ?).
> > I used a WinTV HVR-950/980. Logs enclosed.
> >
> > Regards,
> > Mauro
> 
> Thanks.
> Did you load the module with prefer_bulk=1 ?

No.

> You just started xawtv/tvtime but got no picture, right ?

Yes. I tested also v4l2grab. No frames got returned there.

> 
> There is nothing unusual in the log, except...
> 
> ...
> > [ 8412.464698] xc2028 3-0061: Can't find firmware for type=BASE INIT1 F8MHZ 
> > MTS (4007), id .
> ...
> > [ 8412.464709] xc2028 3-0061: Can't find firmware for type=BASE INIT1 MTS 
> > (4005), id .
> ...

Those are normal. AFAIKT, only firmwares < version 2.0 had init broken into
INIT0 and INIT1.

> > [ 8412.490804] xc2028 3-0061: Can't find firmware for type=MTS SCODE 
> > (2004), id 00010007.

This is ok, as another similar SCODE firmware got loaded.

> 
> and
> 
> ...
> > [ 8454.966006] xc2028 3-0061: xc2028_get_reg 0002 called
> > [ 8454.990113] xc2028 3-0061: i2c input error: rc = -19 (should be 2)
> > [ 8454.996282] xc2028 3-0061: xc2028_signal called
> > [ 8454.997656] xc2028 3-0061: xc2028_get_reg 0002 called
> > [ 8455.021846] xc2028 3-0061: i2c input error: rc = -19 (should be 2)

Those are weird. In any case, as far as I remember, even if xc3028 is bad tuned,
em28xx should be outputing some data. I suspect, however, that those errors
maybe because the em28xx chip has died already.

> 
> Are these errors normal ?
> Are you sure the device is working properly without my patches ?

Yes. See below.

> 
> You could try to load the em28xx module with usb_debug=1.

I'll post it on a separate email.

> 
> Regards,
> Frank
> 
> 

dmesg without your patches:

[  729.964324] Linux video capture interface: v2.00
[  729.968927] WARNING: You are using an experimental version of the media 
stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
8e216e50ddca0550ffd477ce27e843a506b3ae2e [media] it913x [BUG] Enable 
endpoint 3 on devices with HID interface
684259353666b05a148cc70dfeed8e699daedbcd [media] Add Fujitsu Siemens 
Amilo Pi 2530 to gspca upside down table
a66cd0b691c730ed751dbf66ffbd0edf18241790 [media] winbond-cir: do not 
rename input name
[  730.034451] em28xx: New device  WinTV HVR-980 @ 480 Mbps (2040:6513, 
interface 0, class 0)
[  730.042715] em28xx: Audio Vendor Class interface 0 found
[  730.048033] em28xx: Video interface 0 found
[  730.052225] em28xx: DVB interface 0 found
[  730.056320] em28xx #0: chip ID is em2882/em2883
[  730.202750] em28xx #0: i2c eeprom 00: 1a eb 67 95 40 20 13 65 d0 12 5c 03 82 
1e 6a 18
[  730.210868] em28xx #0: i2c eeprom 10: 00 00 24 57 66 07 01 00 00 00 00 00 00 
00 00 00
[  730.218848] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 
1c 00 00
[  730.226821] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 01 01 00 
00 00

Re: [PATCH 10/23] V4L: Add auto focus targets to the selections API

[Sylwester Nawrocki]

Hi Sakari,

On 10/29/2012 09:00 PM, Sakari Ailus wrote:
> On Thu, May 10, 2012 at 12:30:45PM +0200, Sylwester Nawrocki wrote:
>> The camera automatic focus algorithms may require setting up
>> a spot or rectangle coordinates or multiple such parameters.
>>
>> The automatic focus selection targets are introduced in order
>> to allow applications to query and set such coordinates. Those
>> selections are intended to be used together with the automatic
>> focus controls available in the camera control class.
>>
>> Signed-off-by: Sylwester Nawrocki
>> Signed-off-by: Kyungmin Park
>> ---
>>   Documentation/DocBook/media/v4l/selection-api.xml  |   33 
>> +++-
>>   .../DocBook/media/v4l/vidioc-g-selection.xml   |   11 +++
>>   include/linux/videodev2.h  |5 +++
>>   3 files changed, 48 insertions(+), 1 deletion(-)
> 
> What's the status of this patch? May I ask if you have plans to continue
> with it?

Thanks for reminding about it. I'd like to make this ready for v3.8, if 
possible. I've done some minor improvements of the related 
V4L2_CID_AUTO_FOCUS_AREA control and we use this patch internally. We would 
like to see how all this can be used for auto focus feature of the s5c73m3 
camera. I hope to have these patches posted next week.
 
> Speaking of multiple AF windows --- I originally thought we could just have
> multiple selection targets for them. I'm not sure which one would be better;
> multiple selection targets or another field telling the window ID. In case
> of the former we'd leave a largish gap for additional window IDs.
> 
> I think I'm leaning towards using one reserved field for the purpose.

That also as my preference. I imagine the ID field could be reused for
other future or existing selection targets anyway. I recall someone already
asked about multiple ROI support for image cropping [1], perhaps the ID 
field could be used also for that.
 
> Another question I had was that which of the selection rectangles would the
> AF rectangle be related to? Is it the compose bounds rectangle, or the crop
> bounds rectangle, for example? I thought it might make sense to use another
> field to tell that, since I think which one this really is related to is
> purely hardware specific.

It's indeed very hardware specific. I've seen sensors that allow to define
bounds for the auto focus rectangle entirely independent from the output 
format, crop or compose rectangle. It may look strange, but some sensor 
firmwares just accept rectangle/point coordinates with bounds rectangle 
corresponding to video display area (so it is easy, e.g. to use coordinates 
coming directly from a touchscreen) and then perform required calculations 
to map/scale it onto e.g. sensor crop or output rectangle.

I guess your question is related to how to determine in what stage of 
video pipeline the AF selections would be and what the configuration 
order should be from the user space side ?
 
--
Regards,
Sylwester

[1] http://www.spinics.net/lists/linux-media/msg55091.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

Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers

[Frank Schäfer]

Am 29.10.2012 22:03, schrieb Mauro Carvalho Chehab:
> Em Mon, 29 Oct 2012 17:33:12 +0200
> Frank Schäfer  escreveu:
>
>> Am 28.10.2012 21:57, schrieb Mauro Carvalho Chehab:
>>> Em Sun, 21 Oct 2012 19:52:05 +0300
>>> Frank Schäfer  escreveu:
>>>
 This patch series adds support for USB bulk transfers to the em28xx driver.

 Patch 1 is a bugfix for the image data processing with non-interlaced 
 devices (webcams)
 that should be considered for stable (see commit message).

 Patches 2-21 extend the driver to support USB bulk transfers.
 USB endpoint mapping had to be extended and is a bit tricky.
 It might still not be sufficient to handle ALL isoc/bulk endpoints of ALL 
 existing devices,
 but it should work with the devices we have seen so far and (most 
 important !) 
 preserves backwards compatibility to the current driver behavior.
 Isoc endpoints/transfers are preffered by default, patch 21 adds a module 
 parameter to change this behavior.

 The last two patches are follow-up patches not really related to USB 
 tranfers.
 Patch 22 reduces the code size in em28xx-video by merging the two URB data 
 processing functions 
 and patch 23 enables VBI-support for em2840-devices.

 Please note that I could test the changes with an analog non-interlaced 
 non-VBI device only !
 So further tests with DVB/interlaced/VBI devices are strongly recommended !
>>> Did a quick test here with all applied, with analog TV with xawtv and 
>>> tvtime. 
>>> Didn't work.
>> Ok, thanks for testing.
>>
>>> I'll need to postpone it, until I have more time to double check it and 
>>> bisect.
>> I would also need further informations about the test you've made (did
>> you enable bulk ?) and the device you used (supports VBI ?).
> I used a WinTV HVR-950/980. Logs enclosed.
>
> Regards,
> Mauro

Thanks.
Did you load the module with prefer_bulk=1 ?
You just started xawtv/tvtime but got no picture, right ?

There is nothing unusual in the log, except...

...
> [ 8412.464698] xc2028 3-0061: Can't find firmware for type=BASE INIT1 F8MHZ 
> MTS (4007), id .
...
> [ 8412.464709] xc2028 3-0061: Can't find firmware for type=BASE INIT1 MTS 
> (4005), id .
...
> [ 8412.490804] xc2028 3-0061: Can't find firmware for type=MTS SCODE 
> (2004), id 00010007.

and

...
> [ 8454.966006] xc2028 3-0061: xc2028_get_reg 0002 called
> [ 8454.990113] xc2028 3-0061: i2c input error: rc = -19 (should be 2)
> [ 8454.996282] xc2028 3-0061: xc2028_signal called
> [ 8454.997656] xc2028 3-0061: xc2028_get_reg 0002 called
> [ 8455.021846] xc2028 3-0061: i2c input error: rc = -19 (should be 2)

Are these errors normal ?
Are you sure the device is working properly without my patches ?

You could try to load the em28xx module with usb_debug=1.

Regards,
Frank


--
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

[Hans Verkuil]

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 Oct 29 19:00:27 CET 2012
git hash:8f7e91a31fb95c50880c76505b416630c0326d93
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: WARNINGS
linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: WARNINGS
linux-git-x86_64: OK
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-3.5-i686: WARNINGS
linux-3.6-i686: WARNINGS
linux-3.7-rc1-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
linux-3.5-x86_64: WARNINGS
linux-3.6-x86_64: WARNINGS
linux-3.7-rc1-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

Re: [PATCH 00/23] em28xx: add support fur USB bulk transfers

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 17:33:12 +0200
Frank Schäfer  escreveu:

> Am 28.10.2012 21:57, schrieb Mauro Carvalho Chehab:
> > Em Sun, 21 Oct 2012 19:52:05 +0300
> > Frank Schäfer  escreveu:
> >
> >> This patch series adds support for USB bulk transfers to the em28xx driver.
> >>
> >> Patch 1 is a bugfix for the image data processing with non-interlaced 
> >> devices (webcams)
> >> that should be considered for stable (see commit message).
> >>
> >> Patches 2-21 extend the driver to support USB bulk transfers.
> >> USB endpoint mapping had to be extended and is a bit tricky.
> >> It might still not be sufficient to handle ALL isoc/bulk endpoints of ALL 
> >> existing devices,
> >> but it should work with the devices we have seen so far and (most 
> >> important !) 
> >> preserves backwards compatibility to the current driver behavior.
> >> Isoc endpoints/transfers are preffered by default, patch 21 adds a module 
> >> parameter to change this behavior.
> >>
> >> The last two patches are follow-up patches not really related to USB 
> >> tranfers.
> >> Patch 22 reduces the code size in em28xx-video by merging the two URB data 
> >> processing functions 
> >> and patch 23 enables VBI-support for em2840-devices.
> >>
> >> Please note that I could test the changes with an analog non-interlaced 
> >> non-VBI device only !
> >> So further tests with DVB/interlaced/VBI devices are strongly recommended !
> > Did a quick test here with all applied, with analog TV with xawtv and 
> > tvtime. 
> > Didn't work.
> 
> Ok, thanks for testing.
> 
> > I'll need to postpone it, until I have more time to double check it and 
> > bisect.
> 
> I would also need further informations about the test you've made (did
> you enable bulk ?) and the device you used (supports VBI ?).

I used a WinTV HVR-950/980. Logs enclosed.

Regards,
Mauro


[ 8410.539167] media: Linux media interface: v0.10
[ 8410.554658] Linux video capture interface: v2.00
[ 8410.559272] WARNING: You are using an experimental version of the media 
stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
8e216e50ddca0550ffd477ce27e843a506b3ae2e [media] it913x [BUG] Enable 
endpoint 3 on devices with HID interface
684259353666b05a148cc70dfeed8e699daedbcd [media] Add Fujitsu Siemens 
Amilo Pi 2530 to gspca upside down table
a66cd0b691c730ed751dbf66ffbd0edf18241790 [media] winbond-cir: do not 
rename input name
[ 8410.669117] em28xx: New device  WinTV HVR-980 @ 480 Mbps (2040:6513, 
interface 0, class 0)
[ 8410.677360] em28xx: Audio Vendor Class interface 0 found
[ 8410.682652] em28xx: Video interface 0 found
[ 8410.686817] em28xx: DVB interface 0 found
[ 8410.690955] em28xx #0: chip ID is em2882/em2883
[ 8410.837123] em28xx #0: i2c eeprom 00: 1a eb 67 95 40 20 13 65 d0 12 5c 03 82 
1e 6a 18
[ 8410.845092] em28xx #0: i2c eeprom 10: 00 00 24 57 66 07 01 00 00 00 00 00 00 
00 00 00
[ 8410.853063] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 
1c 00 00
[ 8410.861019] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 01 01 00 
00 00 00
[ 8410.868974] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 8410.876926] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00
[ 8410.884901] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 18 03 34 
00 30 00
[ 8410.892874] em28xx #0: i2c eeprom 70: 32 00 38 00 34 00 34 00 39 00 30 00 31 
00 38 00
[ 8410.900838] em28xx #0: i2c eeprom 80: 00 00 1e 03 57 00 69 00 6e 00 54 00 56 
00 20 00
[ 8410.908791] em28xx #0: i2c eeprom 90: 48 00 56 00 52 00 2d 00 39 00 38 00 30 
00 00 00
[ 8410.916743] em28xx #0: i2c eeprom a0: 84 12 00 00 05 50 1a 7f d4 78 23 b1 fe 
d0 18 85
[ 8410.924695] em28xx #0: i2c eeprom b0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 fa 40
[ 8410.932646] em28xx #0: i2c eeprom c0: 1d f0 74 02 01 00 01 79 4f 00 00 00 00 
00 00 00
[ 8410.940596] em28xx #0: i2c eeprom d0: 84 12 00 00 05 50 1a 7f d4 78 23 b1 fe 
d0 18 85
[ 8410.948549] em28xx #0: i2c eeprom e0: ff 00 00 00 04 84 0a 00 01 01 20 77 00 
40 fa 40
[ 8410.956502] em28xx #0: i2c eeprom f0: 1d f0 74 02 01 00 01 79 4f 00 00 00 00 
00 00 00
[ 8410.964459] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x994b2bdd
[ 8410.970959] em28xx #0: EEPROM info:
[ 8410.974431] em28xx #0:   AC97 audio (5 sample rates)
[ 8410.979201] em28xx #0:   500mA max power
[ 8410.982948] em28xx #0:   Table at 0x24, strings=0x1e82, 0x186a, 0x
[ 8410.989277] em28xx #0: Identified as Hauppauge WinTV HVR 950 (card=16)
[ 8410.997388] tveeprom 3-0050: Hauppauge model 65201, rev A1C0, serial# 1917178
[ 8411.004502] tveeprom 3-0050: tuner model is Xceive XC3028 (idx 120, type 71)
[ 8411.011522] tveeprom 3-0050: TV standards PAL(B/G) PAL(I) PAL(D/D1/K) 
ATSC/DVB Digital (eeprom 0xd4)
[ 8411.020646] tveeprom 3-0050: a

Re: [PATCH 10/23] V4L: Add auto focus targets to the selections API

[Sakari Ailus]

Hi Sylwester,

On Thu, May 10, 2012 at 12:30:45PM +0200, Sylwester Nawrocki wrote:
> The camera automatic focus algorithms may require setting up
> a spot or rectangle coordinates or multiple such parameters.
> 
> The automatic focus selection targets are introduced in order
> to allow applications to query and set such coordinates. Those
> selections are intended to be used together with the automatic
> focus controls available in the camera control class.
> 
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Kyungmin Park 
> ---
>  Documentation/DocBook/media/v4l/selection-api.xml  |   33 
> +++-
>  .../DocBook/media/v4l/vidioc-g-selection.xml   |   11 +++
>  include/linux/videodev2.h  |5 +++
>  3 files changed, 48 insertions(+), 1 deletion(-)

What's the status of this patch? May I ask if you have plans to continue
with it?

Speaking of multiple AF windows --- I originally thought we could just have
multiple selection targets for them. I'm not sure which one would be better;
multiple selection targets or another field telling the window ID. In case
of the former we'd leave a largish gap for additional window IDs.

I think I'm leaning towards using one reserved field for the purpose.

Another question I had was that which of the selection rectangles would the
AF rectangle be related to? Is it the compose bounds rectangle, or the crop
bounds rectangle, for example? I thought it might make sense to use another
field to tell that, since I think which one this really is related to is
purely hardware specific.

What do you think?

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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

tidspbridge: ARM common zImage?

[Omar Ramirez Luna]

Hi,

On 26 October 2012 13:00, Tony Lindgren  wrote:
...
>> > I would also like to move the tidspbridge to the DMA API, but I think we'll
>> > need to move step by step there, and using the OMAP IOMMU and IOVMM APIs 
>> > as an
>> > intermediate step would allow splitting patches in reviewable chunks. I 
>> > know
>> > it's a step backwards in term of OMAP IOMMU usage, but that's in my 
>> > opinion a
>> > temporary nuisance to make the leap easier.
>>
>> Since tidspbridge is in staging I guess it's not a problem, though it
>> sounds to me like using the correct API in the first place is going to
>> make less churn.
>
> Not related to these patches, but also sounds like we may need to drop
> some staging/tidspbridge code to be able to move forward with the
> ARM common zImage plans. See the "[GIT PULL] omap plat header removal
> for v3.8 merge window, part1" thread for more info.

I was trying to find some more info on this, but only found one patch
for tidspbridge to delete an include... it seems that I must try with
these patches and see what explodes since we heavily abuse prcm code
too.

Thanks,

Omar
--
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 00/23] em28xx: add support fur USB bulk transfers

[Frank Schäfer]

Am 28.10.2012 21:57, schrieb Mauro Carvalho Chehab:
> Em Sun, 21 Oct 2012 19:52:05 +0300
> Frank Schäfer  escreveu:
>
>> This patch series adds support for USB bulk transfers to the em28xx driver.
>>
>> Patch 1 is a bugfix for the image data processing with non-interlaced 
>> devices (webcams)
>> that should be considered for stable (see commit message).
>>
>> Patches 2-21 extend the driver to support USB bulk transfers.
>> USB endpoint mapping had to be extended and is a bit tricky.
>> It might still not be sufficient to handle ALL isoc/bulk endpoints of ALL 
>> existing devices,
>> but it should work with the devices we have seen so far and (most important 
>> !) 
>> preserves backwards compatibility to the current driver behavior.
>> Isoc endpoints/transfers are preffered by default, patch 21 adds a module 
>> parameter to change this behavior.
>>
>> The last two patches are follow-up patches not really related to USB 
>> tranfers.
>> Patch 22 reduces the code size in em28xx-video by merging the two URB data 
>> processing functions 
>> and patch 23 enables VBI-support for em2840-devices.
>>
>> Please note that I could test the changes with an analog non-interlaced 
>> non-VBI device only !
>> So further tests with DVB/interlaced/VBI devices are strongly recommended !
> Did a quick test here with all applied, with analog TV with xawtv and tvtime. 
> Didn't work.

Ok, thanks for testing.

> I'll need to postpone it, until I have more time to double check it and 
> bisect.

I would also need further informations about the test you've made (did
you enable bulk ?) and the device you used (supports VBI ?).

Regards,
Frank

>
> Regards,
> Mauro

--
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

[PULL] video_visstrim staging/ov7670_for_v3.7

[Javier Martin]

Hi Mauro,
since there was some confusion regarding my two last series
for the ov7670 I've decided to send this pull request to 
make things more clear and avoid merging order issues.

It should apply properly in your current tree.

The following changes since commit 1534e55974c7e2f57623457c0f6b4108c6ef4776:

  media: coda: Add Philipp's patches. (2012-09-24 17:30:53 +0200)

are available in the git repository at:

  https://github.com/jmartinc/video_visstrim.git staging/ov7670_for_v3.7 

for you to fetch changes up to 5a594e1b96d3363aedf74d9bd37a2d669beab0bc:

  ov7670: remove legacy ctrl callbacks. (2012-09-28 13:18:23 +0200)


Javier Martin (9):
  media: ov7670: add support for ov7675.
  media: ov7670: make try_fmt() consistent with 'min_height' and 
'min_width'.
  media: ov7670: calculate framerate properly for ov7675.
  media: ov7670: add possibility to bypass pll for ov7675.
  media: ov7670: Add possibility to disable pixclk during hblank.
  ov7670: use the control framework
  mcam-core: implement the control framework.
  via-camera: implement the control framework.
  ov7670: remove legacy ctrl callbacks.

 drivers/media/i2c/ov7670.c  |  587 +--
 drivers/media/platform/marvell-ccic/mcam-core.c |   54 +--
 drivers/media/platform/marvell-ccic/mcam-core.h |2 +
 drivers/media/platform/via-camera.c |   60 +--
 include/media/ov7670.h  |2 +
 5 files changed, 369 insertions(+), 336 deletions(-)
--
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] saa7134: Add pm_qos_request to fix video corruption

[Simon Farnsworth]

On Monday 29 October 2012 13:44:45 Mauro Carvalho Chehab wrote:
> Thanks for digging into it and getting more data. Do you know if this change
> it also needed with USB devices that do DMA (isoc and/or bulk)? Or the USB
> core already handles that?
> 
I'm not a huge expert - the linux-pm list (cc'd) will have people around who
know more.

If I've understood correctly, though, the USB core should take care of pm_qos
requests if they're needed for the hardware; remember that if the HCD has
enough buffering, there's no need for a pm_qos request. It's only needed for
devices like the SAA7134 where the buffer is small (1K split into pieces)
compared to the sample data rate (27 megabytes/second raw video).

For the benefit of the linux-pm list; this all starts with me providing a
patch to have the saa7134 driver request reduced cpu_dma_latency when
streaming, as I've seen buffer exhaustion. We've got far enough to know that
the value I chose was wrong for the saa7134, but Mauro also wants guidance on
whether USB devices (not host controllers) also need to request reduced
latency.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 14:11 +
Simon Farnsworth  escreveu:

> On Monday 29 October 2012 09:32:27 Andy Walls wrote:
> > On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
> > > It will affect other drivers as well; the basic cause is that modern chips
> > > can enter a package deep sleep state that affects both CPU speed and 
> > > latency
> > > to start of DMA. On older systems, this couldn't happen - the Northbridge
> > > kept running at all times, and DMA latencies were low.
> > > 
> > > However, on the Intel Sandybridge system I'm testing with, the maximum 
> > > wake
> > > latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO 
> > > can't
> > > hold onto data for that long, and overflows, resulting in the corruption 
> > > I'm
> > > seeing. The pm QoS request fixes this for me, by telling the PM subsystem
> > > that the SAA7134 cannot cope with a long latency on the first write of a 
> > > DMA
> > > transfer.
> > > 
> > > Now, some media bridges (like the ones driven by the cx18 driver) can cope
> > > with very high latency before the beginning of a DMA burst. Andy Walls has
> > > worked on the cx18 driver to cope in this situation, so it doesn't fail 
> > > even
> > > with the 109 microsecond DMA latency we have on Sandybridge.
> > 
> > Well if brdige wake-up DMA latency is the problem, it is alos the case
> > that the CX23418 has a *lot* of on board memory with which to collect
> > video and compress it.  (And lets face it, the CX23418 is an SoC with
> > two ARM cores and a lot of dedicated external memory, as opposed to the
> > SAA7134 with 1 kB of FIFO.)   That hardware helps quite a bit, if the
> > PCI bus is slow to wake up.
> > 
> > I found a SAA7134 sheet for you:
> > 
> > http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf
> > 
> > Section 6.4.3 has a short description of the behaviour when the FIFO
> > overflows.
> 
> That's a good description of what I'm seeing, so fits with the idea that it's
> FIFO underflow.
> > 
> > But this sheet (close enough):
> > 
> > http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf
> > 
> > Has much nicer examples of the programmed levels of the FIFO in section
> > 6.4.3.  That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio.
> > So you're lucky if one full line of video fits in the FIFO.
> > 
> And that datasheet suggests that my 31 usec request is too high; in the
> "fastidious" configuration, I'd need a latency of 22 usec, not 31.
> 
> Does anyone have register-level documentation for the SAA7134, to confirm the
> maximum tolerated latency with the FIFO configuration Linux uses?
> 
> > > Others, like the SAA7134, just don't have that much buffering, and we need
> > > to ask the pm core to cope with it. I suspect that most old drivers will 
> > > need
> > > updating if anyone wants to use them with modern systems; either they'll 
> > > have
> > > an architecture like the cx18 series, and the type of work Andy has done 
> > > will
> > > fix the problem, or they'll behave like the saa7134, and need a pm_qos 
> > > request
> > > to ensure that the CPU package (and thus memory controller) stay awake.
> > 
> > Unless the chip has a lot of internal memory and processing resources, I
> > suspect a pm_qos solution is needed to ensure the PCI bus responds in
> > time.
> > 
> > This is a system level issue though.  Having the drivers decide what QoS
> > they need in the absences of total system requirements, is the right
> > thing for the home user.  It might not be very friendly for a
> > professional solution where someone is trying to tune the use of the
> > system IO bandwidth and CPU resources.
> > 
> > The ivtv driver and cx18 driver unconditionally bumping up their PCI
> > latency timer to 64 cycles minimum always bugged me: drivers shouldn't
> > be deciding QoS in a vaccuum.  But, then again, user complaints went
> > away and the 64 PCI cycles seemed to be a minimum QoS that everyone
> > needed.  Also both drivers have a ivtv/cx18_pci_latency module option to
> > override the behaviour anyway.
> > 
> So, one trick that the pm_qos request infrastructure gives us is that I only
> request reduced latency when we are actually streaming. It's up to the pm core
> to determine what that means - e.g. keep CPU awake, program chipset registers,
> ignore the request completely.
> 
> The other part of this is that I'm flagging my QoS requirements; if the wakeup
> latency is higher than I'm requesting, I'll fail - that is clearly wrong. On
> the other hand, if you have reasons to want lower wakeup latencies, the core
> will combine all requests (both userspace and kernelspace), and choose the
> minimum. If you're sophisticated enough to accept the problems involved in not
> waking up in time to service DMA requests, you're probably also up to the task
> of changing the kernel slightly to not request lower latencies.

Andy/Simon,

Thanks for digging into it and getting more data. Do you know if this change
it also needed with USB devic

Re: [PATCH 0/2] Fix a few more warnings

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 15:12:03 +0100
Sylwester Nawrocki  escreveu:

> On 10/29/2012 12:32 PM, Mauro Carvalho Chehab wrote:
> > Em Mon, 29 Oct 2012 12:19:32 +0100
> > Sylwester Nawrocki  escreveu:
> > 
> >> On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
> >>> Hans Verkuil yesterday's build still got two warnings at the
> >>> generic drivers:
> >>> http://hverkuil.home.xs4all.nl/logs/Sunday.log
> >>>
> >>> They didn't appear at i386 build probably because of some
> >>> optimization done there.
> >>>
> >>> Anyway, fixing them are trivial, so let's do it.
> >>>
> >>> After applying those patches, the only drivers left producing
> >>> warnings are the following platform drivers:
> >>>
> >>> drivers/media/platform/davinci/dm355_ccdc.c
> >>> drivers/media/platform/davinci/dm644x_ccdc.c
> >>> drivers/media/platform/davinci/vpbe_osd.c
> >>> drivers/media/platform/omap3isp/ispccdc.c
> >>> drivers/media/platform/omap3isp/isph3a_aewb.c
> >>> drivers/media/platform/omap3isp/isph3a_af.c
> >>> drivers/media/platform/omap3isp/isphist.c
> >>> drivers/media/platform/omap3isp/ispqueue.c
> >>> drivers/media/platform/omap3isp/ispvideo.c
> >>> drivers/media/platform/omap/omap_vout.c
> >>> drivers/media/platform/s5p-fimc/fimc-capture.c
> >>> drivers/media/platform/s5p-fimc/fimc-lite.c
> >>
> >> For these two files I've sent already a pull request [1], which
> >> includes a fixup patch
> >> s5p-fimc: Don't ignore return value of vb2_queue_init()
> >>
> >> BTW, shouldn't things like these be taken care when someone does
> >> a change at the core code ? 
> > 
> > Sure. I remember I saw one patch with s5p on that series[1].
> > Can't remember anymore if it were acked and merged directly, if
> > it was opted to send it via your tree (or maybe that patch was just
> > incomplete, and got unnoticed on that time).
> 
> I think this was one of the first patches from Ezequiel, when he wanted
> to change the vb2_queue_init() function signature so it returns void (as
> there were only BUG_ON()s used inside it). But what we need now at drivers
> is the opposite, i.e. to keep checking the return value and to add where
> such checks are missing. Thus patch [1] is not applicable, since BUG_ONs
> were replaced with WARN_ON and __must_check annotation was added to the
> vb2_queue_init() function declaration.

Ah, ok.

> > [1] https://patchwork.kernel.org/patch/1372871/
> > 
> > It is not easy to enforce those kind of things for platform drivers,
> > as there's not yet a single .config file that could be used to test
> > all arm drivers. Hans automatic builds might be useful, if there weren't
> 
> The ARM arch consolidation efforts are ongoing, for 1.5 year now IIRC
> and there are good results. Still it looks like there is one year or so 
> needed to be able to build one single image usable on all ARM sub-archs.
> I think the progress is good and it all looks very promising, perhaps 
> mostly thanks to the Linaro initiative.

Yeah, when all platform drivers we have can be compiled here, I'll eventually
add it on my test logic. The thing is that changing from one arch to the other
will require doing a make clean, with can be a little painful.
> 
> > any warns at the -git tree build at the tested archs, but there are
> > so many warnings that I think I never saw any such report saying that
> > there's no warning.
> > 
> > Btw, are there anyone really consistently using his reports to fix things?
> 
> Yes, I'm often looking at those logs. I find them useful, especially that 
> it nearly doesn't happen I build some drivers on architectures other than 
> ARM. So it's good to have those build logs.
> 
> Some projects, e.g. [2], use build/test systems that allow to track status
> after each commit. Not sure if something like this is feasible for whole
> media subsystem.
> 
> [2] https://chromium-build.appspot.com/p/chromium/console

The idea is good. The evil is on details. For example, I prefer to not mix
any build setup like that with the main linuxtv site, due to machine's
reliability.

Even running it locally would also likely require two machines, as the 
multi-arch
compilation will take some time, and several GB of diskspace, as each arch will
need a local working copy of the git tree.

Asynchronous compilation of the kernel, while patches are being added has
some issues: if the build fails, patches need to be reverted, as we don't
want to break git bisect. That would mean that we would need a temporary
"untested" tree, and some logic there that will cherry-pick patches to the
"tested" one when compilation succeeds, or stop and warn maintainer if a
patch breaks. The maintainer will then need to rebase the "untested" tree
which can, in tune, cause troubles at the testing daemon.

Anyway, implementing it would require some time and resources 
that I don't currently have. If anyone could do it, that could be
a nice project.

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to

Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Andy Walls]

On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
> On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
> > I prefer if you don't c/c me on that ;) Patchwork is the main source that I 
> > use
> > on my patch reviews.
> > 
> Noted.
> 
> > Btw, I saw your patch yesterday (and skipped it, for now), as I never played
> > with those pm QoS stuff before, nor I ever noticed anything like what you
> > reported on saa7134 (but I can't even remember the last time I tested 
> > something
> > on a saa7134 board ;) - so, it can be some new bug).
> > 
> > So, I'll postpone its review to when I have some time to actually test it
> > especially as the same issue might also be happening on other drivers.
> > 
> It will affect other drivers as well; the basic cause is that modern chips
> can enter a package deep sleep state that affects both CPU speed and latency
> to start of DMA. On older systems, this couldn't happen - the Northbridge
> kept running at all times, and DMA latencies were low.
> 
> However, on the Intel Sandybridge system I'm testing with, the maximum wake
> latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
> hold onto data for that long, and overflows,

BTW

For Y:U:Y:V or raw VBI with a PAL line rate
109 usecs * 15,625 lines/sec ~= 1.7 lines

1.7 lines * 1440 samples/line ~= 2452 samples

2452 samples / 1024 samples/FIFO ~= 2.4 FIFOs

So 109 usecs fully overruns the FIFO by about 1.4 FIFO depths.


>  resulting in the corruption I'm
> seeing. The pm QoS request fixes this for me, by telling the PM subsystem
> that the SAA7134 cannot cope with a long latency on the first write of a DMA
> transfer.

Regards,
Andy

--
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 0/2] Fix a few more warnings

[Sylwester Nawrocki]

On 10/29/2012 12:32 PM, Mauro Carvalho Chehab wrote:
> Em Mon, 29 Oct 2012 12:19:32 +0100
> Sylwester Nawrocki  escreveu:
> 
>> On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
>>> Hans Verkuil yesterday's build still got two warnings at the
>>> generic drivers:
>>> http://hverkuil.home.xs4all.nl/logs/Sunday.log
>>>
>>> They didn't appear at i386 build probably because of some
>>> optimization done there.
>>>
>>> Anyway, fixing them are trivial, so let's do it.
>>>
>>> After applying those patches, the only drivers left producing
>>> warnings are the following platform drivers:
>>>
>>> drivers/media/platform/davinci/dm355_ccdc.c
>>> drivers/media/platform/davinci/dm644x_ccdc.c
>>> drivers/media/platform/davinci/vpbe_osd.c
>>> drivers/media/platform/omap3isp/ispccdc.c
>>> drivers/media/platform/omap3isp/isph3a_aewb.c
>>> drivers/media/platform/omap3isp/isph3a_af.c
>>> drivers/media/platform/omap3isp/isphist.c
>>> drivers/media/platform/omap3isp/ispqueue.c
>>> drivers/media/platform/omap3isp/ispvideo.c
>>> drivers/media/platform/omap/omap_vout.c
>>> drivers/media/platform/s5p-fimc/fimc-capture.c
>>> drivers/media/platform/s5p-fimc/fimc-lite.c
>>
>> For these two files I've sent already a pull request [1], which
>> includes a fixup patch
>> s5p-fimc: Don't ignore return value of vb2_queue_init()
>>
>> BTW, shouldn't things like these be taken care when someone does
>> a change at the core code ? 
> 
> Sure. I remember I saw one patch with s5p on that series[1].
> Can't remember anymore if it were acked and merged directly, if
> it was opted to send it via your tree (or maybe that patch was just
> incomplete, and got unnoticed on that time).

I think this was one of the first patches from Ezequiel, when he wanted
to change the vb2_queue_init() function signature so it returns void (as
there were only BUG_ON()s used inside it). But what we need now at drivers
is the opposite, i.e. to keep checking the return value and to add where
such checks are missing. Thus patch [1] is not applicable, since BUG_ONs
were replaced with WARN_ON and __must_check annotation was added to the
vb2_queue_init() function declaration.

> [1] https://patchwork.kernel.org/patch/1372871/
> 
> It is not easy to enforce those kind of things for platform drivers,
> as there's not yet a single .config file that could be used to test
> all arm drivers. Hans automatic builds might be useful, if there weren't

The ARM arch consolidation efforts are ongoing, for 1.5 year now IIRC
and there are good results. Still it looks like there is one year or so 
needed to be able to build one single image usable on all ARM sub-archs.
I think the progress is good and it all looks very promising, perhaps 
mostly thanks to the Linaro initiative.

> any warns at the -git tree build at the tested archs, but there are
> so many warnings that I think I never saw any such report saying that
> there's no warning.
> 
> Btw, are there anyone really consistently using his reports to fix things?

Yes, I'm often looking at those logs. I find them useful, especially that 
it nearly doesn't happen I build some drivers on architectures other than 
ARM. So it's good to have those build logs.

Some projects, e.g. [2], use build/test systems that allow to track status
after each commit. Not sure if something like this is feasible for whole
media subsystem.

[2] https://chromium-build.appspot.com/p/chromium/console

--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Simon Farnsworth]

On Monday 29 October 2012 09:32:27 Andy Walls wrote:
> On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
> > It will affect other drivers as well; the basic cause is that modern chips
> > can enter a package deep sleep state that affects both CPU speed and latency
> > to start of DMA. On older systems, this couldn't happen - the Northbridge
> > kept running at all times, and DMA latencies were low.
> > 
> > However, on the Intel Sandybridge system I'm testing with, the maximum wake
> > latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO 
> > can't
> > hold onto data for that long, and overflows, resulting in the corruption I'm
> > seeing. The pm QoS request fixes this for me, by telling the PM subsystem
> > that the SAA7134 cannot cope with a long latency on the first write of a DMA
> > transfer.
> > 
> > Now, some media bridges (like the ones driven by the cx18 driver) can cope
> > with very high latency before the beginning of a DMA burst. Andy Walls has
> > worked on the cx18 driver to cope in this situation, so it doesn't fail even
> > with the 109 microsecond DMA latency we have on Sandybridge.
> 
> Well if brdige wake-up DMA latency is the problem, it is alos the case
> that the CX23418 has a *lot* of on board memory with which to collect
> video and compress it.  (And lets face it, the CX23418 is an SoC with
> two ARM cores and a lot of dedicated external memory, as opposed to the
> SAA7134 with 1 kB of FIFO.)   That hardware helps quite a bit, if the
> PCI bus is slow to wake up.
> 
> I found a SAA7134 sheet for you:
> 
> http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf
> 
> Section 6.4.3 has a short description of the behaviour when the FIFO
> overflows.

That's a good description of what I'm seeing, so fits with the idea that it's
FIFO underflow.
> 
> But this sheet (close enough):
> 
> http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf
> 
> Has much nicer examples of the programmed levels of the FIFO in section
> 6.4.3.  That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio.
> So you're lucky if one full line of video fits in the FIFO.
> 
And that datasheet suggests that my 31 usec request is too high; in the
"fastidious" configuration, I'd need a latency of 22 usec, not 31.

Does anyone have register-level documentation for the SAA7134, to confirm the
maximum tolerated latency with the FIFO configuration Linux uses?

> > Others, like the SAA7134, just don't have that much buffering, and we need
> > to ask the pm core to cope with it. I suspect that most old drivers will 
> > need
> > updating if anyone wants to use them with modern systems; either they'll 
> > have
> > an architecture like the cx18 series, and the type of work Andy has done 
> > will
> > fix the problem, or they'll behave like the saa7134, and need a pm_qos 
> > request
> > to ensure that the CPU package (and thus memory controller) stay awake.
> 
> Unless the chip has a lot of internal memory and processing resources, I
> suspect a pm_qos solution is needed to ensure the PCI bus responds in
> time.
> 
> This is a system level issue though.  Having the drivers decide what QoS
> they need in the absences of total system requirements, is the right
> thing for the home user.  It might not be very friendly for a
> professional solution where someone is trying to tune the use of the
> system IO bandwidth and CPU resources.
> 
> The ivtv driver and cx18 driver unconditionally bumping up their PCI
> latency timer to 64 cycles minimum always bugged me: drivers shouldn't
> be deciding QoS in a vaccuum.  But, then again, user complaints went
> away and the 64 PCI cycles seemed to be a minimum QoS that everyone
> needed.  Also both drivers have a ivtv/cx18_pci_latency module option to
> override the behaviour anyway.
> 
So, one trick that the pm_qos request infrastructure gives us is that I only
request reduced latency when we are actually streaming. It's up to the pm core
to determine what that means - e.g. keep CPU awake, program chipset registers,
ignore the request completely.

The other part of this is that I'm flagging my QoS requirements; if the wakeup
latency is higher than I'm requesting, I'll fail - that is clearly wrong. On
the other hand, if you have reasons to want lower wakeup latencies, the core
will combine all requests (both userspace and kernelspace), and choose the
minimum. If you're sophisticated enough to accept the problems involved in not
waking up in time to service DMA requests, you're probably also up to the task
of changing the kernel slightly to not request lower latencies.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Andy Walls]

On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
> On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
> > I prefer if you don't c/c me on that ;) Patchwork is the main source that I 
> > use
> > on my patch reviews.
> > 
> Noted.
> 
> > Btw, I saw your patch yesterday (and skipped it, for now), as I never played
> > with those pm QoS stuff before, nor I ever noticed anything like what you
> > reported on saa7134 (but I can't even remember the last time I tested 
> > something
> > on a saa7134 board ;) - so, it can be some new bug).
> > 
> > So, I'll postpone its review to when I have some time to actually test it
> > especially as the same issue might also be happening on other drivers.
> > 
> It will affect other drivers as well; the basic cause is that modern chips
> can enter a package deep sleep state that affects both CPU speed and latency
> to start of DMA. On older systems, this couldn't happen - the Northbridge
> kept running at all times, and DMA latencies were low.
> 
> However, on the Intel Sandybridge system I'm testing with, the maximum wake
> latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
> hold onto data for that long, and overflows, resulting in the corruption I'm
> seeing. The pm QoS request fixes this for me, by telling the PM subsystem
> that the SAA7134 cannot cope with a long latency on the first write of a DMA
> transfer.
> 
> Now, some media bridges (like the ones driven by the cx18 driver) can cope
> with very high latency before the beginning of a DMA burst. Andy Walls has
> worked on the cx18 driver to cope in this situation, so it doesn't fail even
> with the 109 microsecond DMA latency we have on Sandybridge.

Well if brdige wake-up DMA latency is the problem, it is alos the case
that the CX23418 has a *lot* of on board memory with which to collect
video and compress it.  (And lets face it, the CX23418 is an SoC with
two ARM cores and a lot of dedicated external memory, as opposed to the
SAA7134 with 1 kB of FIFO.)   That hardware helps quite a bit, if the
PCI bus is slow to wake up.

I found a SAA7134 sheet for you:

http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf

Section 6.4.3 has a short description of the behaviour when the FIFO
overflows.

But this sheet (close enough):

http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf

Has much nicer examples of the programmed levels of the FIFO in section
6.4.3.  That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio.
So you're lucky if one full line of video fits in the FIFO.

> Others, like the SAA7134, just don't have that much buffering, and we need
> to ask the pm core to cope with it. I suspect that most old drivers will need
> updating if anyone wants to use them with modern systems; either they'll have
> an architecture like the cx18 series, and the type of work Andy has done will
> fix the problem, or they'll behave like the saa7134, and need a pm_qos request
> to ensure that the CPU package (and thus memory controller) stay awake.

Unless the chip has a lot of internal memory and processing resources, I
suspect a pm_qos solution is needed to ensure the PCI bus responds in
time.

This is a system level issue though.  Having the drivers decide what QoS
they need in the absences of total system requirements, is the right
thing for the home user.  It might not be very friendly for a
professional solution where someone is trying to tune the use of the
system IO bandwidth and CPU resources.

The ivtv driver and cx18 driver unconditionally bumping up their PCI
latency timer to 64 cycles minimum always bugged me: drivers shouldn't
be deciding QoS in a vaccuum.  But, then again, user complaints went
away and the 64 PCI cycles seemed to be a minimum QoS that everyone
needed.  Also both drivers have a ivtv/cx18_pci_latency module option to
override the behaviour anyway.


-Andy

--
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 35/68] [media] pwc-if: must check vb2_queue_init() success

[Ezequiel Garcia]

On Mon, Oct 29, 2012 at 8:44 AM, Mauro Carvalho Chehab
 wrote:
> Em Mon, 29 Oct 2012 08:37:31 -0300
> Ezequiel Garcia  escreveu:
>
>> On Sat, Oct 27, 2012 at 5:40 PM, Mauro Carvalho Chehab
>>  wrote:
>> > drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
>> > drivers/media/usb/pwc/pwc-if.c:1003:16: warning: ignoring return value of 
>> > 'vb2_queue_init', declared with attribute warn_unused_result 
>> > [-Wunused-result]
>> > In the past, it used to have a logic there at queue init that would
>> > BUG() on errors. This logic got removed. Drivers are now required
>> > to explicitly handle the queue initialization errors, or very bad
>> > things may happen.
>> >
>> > Signed-off-by: Mauro Carvalho Chehab 
>> > ---
>> >  drivers/media/usb/pwc/pwc-if.c | 6 +-
>> >  1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/media/usb/pwc/pwc-if.c 
>> > b/drivers/media/usb/pwc/pwc-if.c
>> > index e191572..5210239 100644
>> > --- a/drivers/media/usb/pwc/pwc-if.c
>> > +++ b/drivers/media/usb/pwc/pwc-if.c
>> > @@ -1000,7 +1000,11 @@ static int usb_pwc_probe(struct usb_interface 
>> > *intf, const struct usb_device_id
>> > pdev->vb_queue.buf_struct_size = sizeof(struct pwc_frame_buf);
>> > pdev->vb_queue.ops = &pwc_vb_queue_ops;
>> > pdev->vb_queue.mem_ops = &vb2_vmalloc_memops;
>> > -   vb2_queue_init(&pdev->vb_queue);
>> > +   rc = vb2_queue_init(&pdev->vb_queue);
>> > +   if (rc < 0) {
>> > +   PWC_ERROR("Oops, could not initialize vb2 queue.\n");
>> > +   goto err_free_mem;
>> > +   }
>> >
>> > /* Init video_device structure */
>> > memcpy(&pdev->vdev, &pwc_template, sizeof(pwc_template));
>> > --
>> > 1.7.11.7
>> >
>>
>> Weird, I thought this was already fixed...
>>
>> https://patchwork.kernel.org/patch/1467211/
>>
>> And even weirder...
>> now all my patches are marked as 'New' by patchwork...
>>
>> https://patchwork.kernel.org/project/linux-media/list/?submitter=37031&state=*
>>
>> (this must be the last name mess I did...)
>
> Nah, you're looking at the wrong place. you should be looking at 
> patchwork.linuxtv.org.

Yeah... I don't know why da heck I was looking there!

Sorry for the noise ;-)

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: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Simon Farnsworth]

On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
> I prefer if you don't c/c me on that ;) Patchwork is the main source that I 
> use
> on my patch reviews.
> 
Noted.

> Btw, I saw your patch yesterday (and skipped it, for now), as I never played
> with those pm QoS stuff before, nor I ever noticed anything like what you
> reported on saa7134 (but I can't even remember the last time I tested 
> something
> on a saa7134 board ;) - so, it can be some new bug).
> 
> So, I'll postpone its review to when I have some time to actually test it
> especially as the same issue might also be happening on other drivers.
> 
It will affect other drivers as well; the basic cause is that modern chips
can enter a package deep sleep state that affects both CPU speed and latency
to start of DMA. On older systems, this couldn't happen - the Northbridge
kept running at all times, and DMA latencies were low.

However, on the Intel Sandybridge system I'm testing with, the maximum wake
latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
hold onto data for that long, and overflows, resulting in the corruption I'm
seeing. The pm QoS request fixes this for me, by telling the PM subsystem
that the SAA7134 cannot cope with a long latency on the first write of a DMA
transfer.

Now, some media bridges (like the ones driven by the cx18 driver) can cope
with very high latency before the beginning of a DMA burst. Andy Walls has
worked on the cx18 driver to cope in this situation, so it doesn't fail even
with the 109 microsecond DMA latency we have on Sandybridge.

Others, like the SAA7134, just don't have that much buffering, and we need
to ask the pm core to cope with it. I suspect that most old drivers will need
updating if anyone wants to use them with modern systems; either they'll have
an architecture like the cx18 series, and the type of work Andy has done will
fix the problem, or they'll behave like the saa7134, and need a pm_qos request
to ensure that the CPU package (and thus memory controller) stay awake.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com


signature.asc
Description: This is a digitally signed message part.

[PATCH v2] media: coda: Fix H.264 header alignment.

[javier . martin]

From: Javier Martin 

Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.

In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.

Signed-off-by: Javier Martin 
---
Changes since v1:
 - Align to 64bits as requested by Philipp.

---
 drivers/media/platform/coda.c |   30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index a8c7a94..7febcd9 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -177,6 +177,10 @@ struct coda_ctx {
int idx;
 };
 
+static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
+   0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
+static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 };
+
 static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg)
 {
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
@@ -938,6 +942,24 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx, 
struct coda_q_data *q_d
return 0;
 }
 
+static int coda_h264_padding(int size, char *p)
+{
+   int nal_size;
+   int diff;
+
+   diff = size - (size & ~0x7);
+   if (diff == 0)
+   return 0;
+
+   nal_size = coda_filler_size[diff];
+   memcpy(p, coda_filler_nal, nal_size);
+
+   /* Add rbsp stop bit and trailing at the end */
+   *(p + nal_size - 1) = 0x80;
+
+   return nal_size;
+}
+
 static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
 {
struct coda_ctx *ctx = vb2_get_drv_priv(q);
@@ -1165,7 +1187,13 @@ static int coda_start_streaming(struct vb2_queue *q, 
unsigned int count)
coda_read(dev, CODA_CMD_ENC_HEADER_BB_START);
memcpy(&ctx->vpu_header[1][0], vb2_plane_vaddr(buf, 0),
   ctx->vpu_header_size[1]);
-   ctx->vpu_header_size[2] = 0;
+   /*
+* Length of H.264 headers is variable and thus it might not be
+* aligned for the coda to append the encoded frame. In that is
+* the case a filler NAL must be added to header 2.
+*/
+   ctx->vpu_header_size[2] = 
coda_h264_padding((ctx->vpu_header_size[0] +
+   ctx->vpu_header_size[1]), 
ctx->vpu_header[2]);
break;
case V4L2_PIX_FMT_MPEG4:
/*
-- 
1.7.9.5

--
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] saa7134: Add pm_qos_request to fix video corruption

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 11:25:38 +
Simon Farnsworth  escreveu:

> On Monday 22 October 2012 12:50:11 Simon Farnsworth wrote:
> > The SAA7134 appears to have trouble buffering more than one line of video
> > when doing DMA. Rather than try to fix the driver to cope (as has been done
> > by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep
> > sleep exit latencies.
> > 
> > The visible effect of not having this is that seemingly random lines are
> > only partly transferred - if you feed in a static image, you see a portion
> > of the image "flicker" into place.
> > 
> > Signed-off-by: Simon Farnsworth 
> 
> Hello Mauro,
> 
> I've just noticed that I forgot to CC you in on this patch I sent last week - 
> Patchwork grabbed it at https://patchwork.kernel.org/patch/1625311/ but if 
> you 
> want me to resend it so that you've got it in a mailbox for consideration, 
> just let me know.

I prefer if you don't c/c me on that ;) Patchwork is the main source that I use
on my patch reviews.

Btw, I saw your patch yesterday (and skipped it, for now), as I never played
with those pm QoS stuff before, nor I ever noticed anything like what you
reported on saa7134 (but I can't even remember the last time I tested something
on a saa7134 board ;) - so, it can be some new bug).

So, I'll postpone its review to when I have some time to actually test it
especially as the same issue might also be happening on other drivers.

Cheers,
Mauro
--
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 35/68] [media] pwc-if: must check vb2_queue_init() success

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 08:37:31 -0300
Ezequiel Garcia  escreveu:

> On Sat, Oct 27, 2012 at 5:40 PM, Mauro Carvalho Chehab
>  wrote:
> > drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
> > drivers/media/usb/pwc/pwc-if.c:1003:16: warning: ignoring return value of 
> > 'vb2_queue_init', declared with attribute warn_unused_result 
> > [-Wunused-result]
> > In the past, it used to have a logic there at queue init that would
> > BUG() on errors. This logic got removed. Drivers are now required
> > to explicitly handle the queue initialization errors, or very bad
> > things may happen.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/usb/pwc/pwc-if.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> > index e191572..5210239 100644
> > --- a/drivers/media/usb/pwc/pwc-if.c
> > +++ b/drivers/media/usb/pwc/pwc-if.c
> > @@ -1000,7 +1000,11 @@ static int usb_pwc_probe(struct usb_interface *intf, 
> > const struct usb_device_id
> > pdev->vb_queue.buf_struct_size = sizeof(struct pwc_frame_buf);
> > pdev->vb_queue.ops = &pwc_vb_queue_ops;
> > pdev->vb_queue.mem_ops = &vb2_vmalloc_memops;
> > -   vb2_queue_init(&pdev->vb_queue);
> > +   rc = vb2_queue_init(&pdev->vb_queue);
> > +   if (rc < 0) {
> > +   PWC_ERROR("Oops, could not initialize vb2 queue.\n");
> > +   goto err_free_mem;
> > +   }
> >
> > /* Init video_device structure */
> > memcpy(&pdev->vdev, &pwc_template, sizeof(pwc_template));
> > --
> > 1.7.11.7
> >
> 
> Weird, I thought this was already fixed...
> 
> https://patchwork.kernel.org/patch/1467211/
> 
> And even weirder...
> now all my patches are marked as 'New' by patchwork...
> 
> https://patchwork.kernel.org/project/linux-media/list/?submitter=37031&state=*
> 
> (this must be the last name mess I did...)

Nah, you're looking at the wrong place. you should be looking at 
patchwork.linuxtv.org.

The ones I have with your name on it are those:

patches/lmml_15142_01_23_uvc_replace_memcpy_with_struct_assignment.patch
patches/lmml_15143_22_23_radio_wl1273_replace_memcpy_with_struct_assignment.patch
patches/lmml_15144_23_23_wl128x_replace_memcpy_with_struct_assignment.patch
patches/lmml_15145_21_23_dvb_frontends_replace_memcpy_with_struct_assignment.patch
patches/lmml_15146_20_23_dvb_core_replace_memcpy_with_struct_assignment.patch
patches/lmml_15147_18_23_cx18_replace_memcpy_with_struct_assignment.patch
patches/lmml_15148_19_23_bttv_replace_memcpy_with_struct_assignment.patch
patches/lmml_15149_17_23_cx23885_replace_memcpy_with_struct_assignment.patch
patches/lmml_15150_16_23_cx88_replace_memcpy_with_struct_assignment.patch
patches/lmml_15151_14_23_tuners_tda18271_replace_memcpy_with_struct_assignment.patch
patches/lmml_15152_15_23_ivtv_replace_memcpy_with_struct_assignment.patch
patches/lmml_15153_12_23_tuners_xc4000_replace_memcpy_with_struct_assignment.patch
patches/lmml_15154_13_23_tuners_xc2028_replace_memcpy_with_struct_assignment.patch
patches/lmml_15155_11_23_au0828_replace_memcpy_with_struct_assignment.patch
patches/lmml_15156_10_23_dvb_usb_friio_fe_replace_memcpy_with_struct_assignment.patch
patches/lmml_15157_08_23_cx25840_replace_memcpy_with_struct_assignment.patch
patches/lmml_15158_09_23_zr36067_replace_memcpy_with_struct_assignment.patch
patches/lmml_15159_06_23_pvrusb2_replace_memcpy_with_struct_assignment.patch
patches/lmml_15160_07_23_hdpvr_replace_memcpy_with_struct_assignment.patch
patches/lmml_15161_05_23_pwc_replace_memcpy_with_struct_assignment.patch
patches/lmml_15162_04_23_sn9c102_replace_memcpy_with_struct_assignment.patch
patches/lmml_15163_03_23_usbvision_replace_memcpy_with_struct_assignment.patch
patches/lmml_15164_02_23_cx231xx_replace_memcpy_with_struct_assignment.patch
patches/lmml_15165_stk1160_try_to_continue_with_fewer_transfer_buffers.patch
patches/lmml_14192_11_14_drivers_media_usb_stk1160_stk1160_i2c_c_fix_error_return_code.patch
patches/lmml_15197_maintainers_update_email_and_git_tree.patch


> 
> 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


-- 
Regards,
Mauro
--
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 35/68] [media] pwc-if: must check vb2_queue_init() success

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 08:37:31 -0300
Ezequiel Garcia  escreveu:

> On Sat, Oct 27, 2012 at 5:40 PM, Mauro Carvalho Chehab
>  wrote:
> > drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
> > drivers/media/usb/pwc/pwc-if.c:1003:16: warning: ignoring return value of 
> > 'vb2_queue_init', declared with attribute warn_unused_result 
> > [-Wunused-result]
> > In the past, it used to have a logic there at queue init that would
> > BUG() on errors. This logic got removed. Drivers are now required
> > to explicitly handle the queue initialization errors, or very bad
> > things may happen.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  drivers/media/usb/pwc/pwc-if.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> > index e191572..5210239 100644
> > --- a/drivers/media/usb/pwc/pwc-if.c
> > +++ b/drivers/media/usb/pwc/pwc-if.c
> > @@ -1000,7 +1000,11 @@ static int usb_pwc_probe(struct usb_interface *intf, 
> > const struct usb_device_id
> > pdev->vb_queue.buf_struct_size = sizeof(struct pwc_frame_buf);
> > pdev->vb_queue.ops = &pwc_vb_queue_ops;
> > pdev->vb_queue.mem_ops = &vb2_vmalloc_memops;
> > -   vb2_queue_init(&pdev->vb_queue);
> > +   rc = vb2_queue_init(&pdev->vb_queue);
> > +   if (rc < 0) {
> > +   PWC_ERROR("Oops, could not initialize vb2 queue.\n");
> > +   goto err_free_mem;
> > +   }
> >
> > /* Init video_device structure */
> > memcpy(&pdev->vdev, &pwc_template, sizeof(pwc_template));
> > --
> > 1.7.11.7
> >
> 
> Weird, I thought this was already fixed...
> 
> https://patchwork.kernel.org/patch/1467211/
> 
> And even weirder...
> now all my patches are marked as 'New' by patchwork...
> 
> https://patchwork.kernel.org/project/linux-media/list/?submitter=37031&state=*
> 
> (this must be the last name mess I did...)

That's really weird. Did you receive the patchwork state notification email 
for any of those patches?
> 
> 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


-- 
Regards,
Mauro
--
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 0/2] Fix a few more warnings

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 11:38:39 +0100
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Monday 29 October 2012 08:21:56 Mauro Carvalho Chehab wrote:
> > Hans Verkuil yesterday's build still got two warnings at the
> > generic drivers:
> > http://hverkuil.home.xs4all.nl/logs/Sunday.log
> > 
> > They didn't appear at i386 build probably because of some
> > optimization done there.
> > 
> > Anyway, fixing them are trivial, so let's do it.
> > 
> > After applying those patches, the only drivers left producing
> > warnings are the following platform drivers:
> > 
> > drivers/media/platform/davinci/dm355_ccdc.c
> > drivers/media/platform/davinci/dm644x_ccdc.c
> > drivers/media/platform/davinci/vpbe_osd.c
> > drivers/media/platform/omap3isp/ispccdc.c
> > drivers/media/platform/omap3isp/isph3a_aewb.c
> > drivers/media/platform/omap3isp/isph3a_af.c
> > drivers/media/platform/omap3isp/isphist.c
> > drivers/media/platform/omap3isp/ispqueue.c
> > drivers/media/platform/omap3isp/ispvideo.c
> > drivers/media/platform/omap/omap_vout.c
> > drivers/media/platform/s5p-fimc/fimc-capture.c
> > drivers/media/platform/s5p-fimc/fimc-lite.c
> > drivers/media/platform/sh_vou.c
> > drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> > 
> > Platform driver maintainers: please fix, as those warnings could be
> > hiding real bugs.
> 
> I've sent you a pull request for v3.7 on Thu, 25 Oct 2012 with two patches 
> that fix most of the warnings:
> 
>   omap3isp: video: Fix warning caused by bad vidioc_s_crop prototype
>   omap3isp: Fix warning caused by bad subdev events operations prototypes

Ok. I'll review it today.

> The other two OMAP3 ISP warnings are false positive. They will go away when 
> we'll switch to videobuf2 (which is on my to-do list).

While you're not ready to submit the omap3 vb2 patches, would you mind fixing
them? Failing to do that will prevent us to improve the process of detecting
warnings at day zero. For example, I suspect that  Hans automatic compilation
tool will keep saying that WARNINGS are present at -git, while we don't fix
all those platform warnings.

Regards,
Mauro
--
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 0/2] Fix a few more warnings

[Ezequiel Garcia]

On Mon, Oct 29, 2012 at 8:32 AM, Mauro Carvalho Chehab
 wrote:
> Em Mon, 29 Oct 2012 12:19:32 +0100
> Sylwester Nawrocki  escreveu:
>
>> On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
>> > Hans Verkuil yesterday's build still got two warnings at the
>> > generic drivers:
>> > http://hverkuil.home.xs4all.nl/logs/Sunday.log
>> >
>> > They didn't appear at i386 build probably because of some
>> > optimization done there.
>> >
>> > Anyway, fixing them are trivial, so let's do it.
>> >
>> > After applying those patches, the only drivers left producing
>> > warnings are the following platform drivers:
>> >
>> > drivers/media/platform/davinci/dm355_ccdc.c
>> > drivers/media/platform/davinci/dm644x_ccdc.c
>> > drivers/media/platform/davinci/vpbe_osd.c
>> > drivers/media/platform/omap3isp/ispccdc.c
>> > drivers/media/platform/omap3isp/isph3a_aewb.c
>> > drivers/media/platform/omap3isp/isph3a_af.c
>> > drivers/media/platform/omap3isp/isphist.c
>> > drivers/media/platform/omap3isp/ispqueue.c
>> > drivers/media/platform/omap3isp/ispvideo.c
>> > drivers/media/platform/omap/omap_vout.c
>> > drivers/media/platform/s5p-fimc/fimc-capture.c
>> > drivers/media/platform/s5p-fimc/fimc-lite.c
>>
>> For these two files I've sent already a pull request [1], which
>> includes a fixup patch
>> s5p-fimc: Don't ignore return value of vb2_queue_init()
>>
>> BTW, shouldn't things like these be taken care when someone does
>> a change at the core code ?
>
> Sure. I remember I saw one patch with s5p on that series[1].
> Can't remember anymore if it were acked and merged directly, if
> it was opted to send it via your tree (or maybe that patch was just
> incomplete, and got unnoticed on that time).
>
> [1] https://patchwork.kernel.org/patch/1372871/
>
> It is not easy to enforce those kind of things for platform drivers,
> as there's not yet a single .config file that could be used to test
> all arm drivers. Hans automatic builds might be useful, if there weren't
> any warns at the -git tree build at the tested archs, but there are
> so many warnings that I think I never saw any such report saying that
> there's no warning.
>
> Btw, are there anyone really consistently using his reports to fix things?
>

I do.

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: [PATCH 35/68] [media] pwc-if: must check vb2_queue_init() success

[Ezequiel Garcia]

On Sat, Oct 27, 2012 at 5:40 PM, Mauro Carvalho Chehab
 wrote:
> drivers/media/usb/pwc/pwc-if.c: In function 'usb_pwc_probe':
> drivers/media/usb/pwc/pwc-if.c:1003:16: warning: ignoring return value of 
> 'vb2_queue_init', declared with attribute warn_unused_result [-Wunused-result]
> In the past, it used to have a logic there at queue init that would
> BUG() on errors. This logic got removed. Drivers are now required
> to explicitly handle the queue initialization errors, or very bad
> things may happen.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/pwc/pwc-if.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> index e191572..5210239 100644
> --- a/drivers/media/usb/pwc/pwc-if.c
> +++ b/drivers/media/usb/pwc/pwc-if.c
> @@ -1000,7 +1000,11 @@ static int usb_pwc_probe(struct usb_interface *intf, 
> const struct usb_device_id
> pdev->vb_queue.buf_struct_size = sizeof(struct pwc_frame_buf);
> pdev->vb_queue.ops = &pwc_vb_queue_ops;
> pdev->vb_queue.mem_ops = &vb2_vmalloc_memops;
> -   vb2_queue_init(&pdev->vb_queue);
> +   rc = vb2_queue_init(&pdev->vb_queue);
> +   if (rc < 0) {
> +   PWC_ERROR("Oops, could not initialize vb2 queue.\n");
> +   goto err_free_mem;
> +   }
>
> /* Init video_device structure */
> memcpy(&pdev->vdev, &pwc_template, sizeof(pwc_template));
> --
> 1.7.11.7
>

Weird, I thought this was already fixed...

https://patchwork.kernel.org/patch/1467211/

And even weirder...
now all my patches are marked as 'New' by patchwork...

https://patchwork.kernel.org/project/linux-media/list/?submitter=37031&state=*

(this must be the last name mess I did...)

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: [PATCH 0/2] Fix a few more warnings

[Mauro Carvalho Chehab]

Em Mon, 29 Oct 2012 12:19:32 +0100
Sylwester Nawrocki  escreveu:

> On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
> > Hans Verkuil yesterday's build still got two warnings at the
> > generic drivers:
> > http://hverkuil.home.xs4all.nl/logs/Sunday.log
> > 
> > They didn't appear at i386 build probably because of some
> > optimization done there.
> > 
> > Anyway, fixing them are trivial, so let's do it.
> > 
> > After applying those patches, the only drivers left producing
> > warnings are the following platform drivers:
> > 
> > drivers/media/platform/davinci/dm355_ccdc.c
> > drivers/media/platform/davinci/dm644x_ccdc.c
> > drivers/media/platform/davinci/vpbe_osd.c
> > drivers/media/platform/omap3isp/ispccdc.c
> > drivers/media/platform/omap3isp/isph3a_aewb.c
> > drivers/media/platform/omap3isp/isph3a_af.c
> > drivers/media/platform/omap3isp/isphist.c
> > drivers/media/platform/omap3isp/ispqueue.c
> > drivers/media/platform/omap3isp/ispvideo.c
> > drivers/media/platform/omap/omap_vout.c
> > drivers/media/platform/s5p-fimc/fimc-capture.c
> > drivers/media/platform/s5p-fimc/fimc-lite.c
> 
> For these two files I've sent already a pull request [1], which
> includes a fixup patch
> s5p-fimc: Don't ignore return value of vb2_queue_init()
> 
> BTW, shouldn't things like these be taken care when someone does
> a change at the core code ? 

Sure. I remember I saw one patch with s5p on that series[1].
Can't remember anymore if it were acked and merged directly, if
it was opted to send it via your tree (or maybe that patch was just
incomplete, and got unnoticed on that time).

[1] https://patchwork.kernel.org/patch/1372871/

It is not easy to enforce those kind of things for platform drivers,
as there's not yet a single .config file that could be used to test
all arm drivers. Hans automatic builds might be useful, if there weren't
any warns at the -git tree build at the tested archs, but there are
so many warnings that I think I never saw any such report saying that
there's no warning.

Btw, are there anyone really consistently using his reports to fix things?

> I'm not having issues in this case at all,
> but if there is many people doing constantly changes at the core it
> might imply for driver authors/maintainers wasting much of their time
> for fixing issues resulting from constant changes at the base code.

Regards,
Mauro
--
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 0/2] Fix a few more warnings

[Ezequiel Garcia]

On Mon, Oct 29, 2012 at 8:19 AM, Sylwester Nawrocki
 wrote:
> On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
>> Hans Verkuil yesterday's build still got two warnings at the
>> generic drivers:
>> http://hverkuil.home.xs4all.nl/logs/Sunday.log
>>
>> They didn't appear at i386 build probably because of some
>> optimization done there.
>>
>> Anyway, fixing them are trivial, so let's do it.
>>
>> After applying those patches, the only drivers left producing
>> warnings are the following platform drivers:
>>
>> drivers/media/platform/davinci/dm355_ccdc.c
>> drivers/media/platform/davinci/dm644x_ccdc.c
>> drivers/media/platform/davinci/vpbe_osd.c
>> drivers/media/platform/omap3isp/ispccdc.c
>> drivers/media/platform/omap3isp/isph3a_aewb.c
>> drivers/media/platform/omap3isp/isph3a_af.c
>> drivers/media/platform/omap3isp/isphist.c
>> drivers/media/platform/omap3isp/ispqueue.c
>> drivers/media/platform/omap3isp/ispvideo.c
>> drivers/media/platform/omap/omap_vout.c
>> drivers/media/platform/s5p-fimc/fimc-capture.c
>> drivers/media/platform/s5p-fimc/fimc-lite.c
>
> For these two files I've sent already a pull request [1], which
> includes a fixup patch
> s5p-fimc: Don't ignore return value of vb2_queue_init()
>
> BTW, shouldn't things like these be taken care when someone does
> a change at the core code ? I'm not having issues in this case at all,
> but if there is many people doing constantly changes at the core it
> might imply for driver authors/maintainers wasting much of their time
> for fixing issues resulting from constant changes at the base code.
>

Indeed. When I changed vb2_queue_init() to return something,
I went and fix every user. I don't know why I missed those.

My bad,

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: [PATCH] saa7134: Add pm_qos_request to fix video corruption

[Simon Farnsworth]

On Monday 22 October 2012 12:50:11 Simon Farnsworth wrote:
> The SAA7134 appears to have trouble buffering more than one line of video
> when doing DMA. Rather than try to fix the driver to cope (as has been done
> by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep
> sleep exit latencies.
> 
> The visible effect of not having this is that seemingly random lines are
> only partly transferred - if you feed in a static image, you see a portion
> of the image "flicker" into place.
> 
> Signed-off-by: Simon Farnsworth 

Hello Mauro,

I've just noticed that I forgot to CC you in on this patch I sent last week - 
Patchwork grabbed it at https://patchwork.kernel.org/patch/1625311/ but if you 
want me to resend it so that you've got it in a mailbox for consideration, 
just let me know.
-- 
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 0/2] Fix a few more warnings

[Sylwester Nawrocki]

On 10/29/2012 11:21 AM, Mauro Carvalho Chehab wrote:
> Hans Verkuil yesterday's build still got two warnings at the
> generic drivers:
> http://hverkuil.home.xs4all.nl/logs/Sunday.log
> 
> They didn't appear at i386 build probably because of some
> optimization done there.
> 
> Anyway, fixing them are trivial, so let's do it.
> 
> After applying those patches, the only drivers left producing
> warnings are the following platform drivers:
> 
> drivers/media/platform/davinci/dm355_ccdc.c
> drivers/media/platform/davinci/dm644x_ccdc.c
> drivers/media/platform/davinci/vpbe_osd.c
> drivers/media/platform/omap3isp/ispccdc.c
> drivers/media/platform/omap3isp/isph3a_aewb.c
> drivers/media/platform/omap3isp/isph3a_af.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/media/platform/omap3isp/ispqueue.c
> drivers/media/platform/omap3isp/ispvideo.c
> drivers/media/platform/omap/omap_vout.c
> drivers/media/platform/s5p-fimc/fimc-capture.c
> drivers/media/platform/s5p-fimc/fimc-lite.c

For these two files I've sent already a pull request [1], which
includes a fixup patch
s5p-fimc: Don't ignore return value of vb2_queue_init()

BTW, shouldn't things like these be taken care when someone does
a change at the core code ? I'm not having issues in this case at all,
but if there is many people doing constantly changes at the core it
might imply for driver authors/maintainers wasting much of their time
for fixing issues resulting from constant changes at the base code.

Thanks,
Sylwester

> drivers/media/platform/sh_vou.c
> drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> 
> Platform driver maintainers: please fix, as those warnings could be
> hiding real bugs. Also, removing all warnings is interesting,
> as they helps to detect when new possible bugs got introduced.
> 
> I think Hans also use "make W=1" option when doing his tests.
> 
> Mauro Carvalho Chehab (2):
>   [media] drxk_hard: fix the return code from an error handler
>   [media] xc4000: Fix a few warnings
> 
>  drivers/media/dvb-frontends/drxk_hard.c | 1 +
>  drivers/media/tuners/xc4000.c   | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)

[1] http://patchwork.linuxtv.org/patch/15195/

--
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 0/2] Fix a few more warnings

[Laurent Pinchart]

Hi Mauro,

On Monday 29 October 2012 08:21:56 Mauro Carvalho Chehab wrote:
> Hans Verkuil yesterday's build still got two warnings at the
> generic drivers:
> http://hverkuil.home.xs4all.nl/logs/Sunday.log
> 
> They didn't appear at i386 build probably because of some
> optimization done there.
> 
> Anyway, fixing them are trivial, so let's do it.
> 
> After applying those patches, the only drivers left producing
> warnings are the following platform drivers:
> 
> drivers/media/platform/davinci/dm355_ccdc.c
> drivers/media/platform/davinci/dm644x_ccdc.c
> drivers/media/platform/davinci/vpbe_osd.c
> drivers/media/platform/omap3isp/ispccdc.c
> drivers/media/platform/omap3isp/isph3a_aewb.c
> drivers/media/platform/omap3isp/isph3a_af.c
> drivers/media/platform/omap3isp/isphist.c
> drivers/media/platform/omap3isp/ispqueue.c
> drivers/media/platform/omap3isp/ispvideo.c
> drivers/media/platform/omap/omap_vout.c
> drivers/media/platform/s5p-fimc/fimc-capture.c
> drivers/media/platform/s5p-fimc/fimc-lite.c
> drivers/media/platform/sh_vou.c
> drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
> 
> Platform driver maintainers: please fix, as those warnings could be
> hiding real bugs.

I've sent you a pull request for v3.7 on Thu, 25 Oct 2012 with two patches 
that fix most of the warnings:

  omap3isp: video: Fix warning caused by bad vidioc_s_crop prototype
  omap3isp: Fix warning caused by bad subdev events operations prototypes

The other two OMAP3 ISP warnings are false positive. They will go away when 
we'll switch to videobuf2 (which is on my to-do list).

> Also, removing all warnings is interesting, as they helps to detect when new
> possible bugs got introduced.
> 
> I think Hans also use "make W=1" option when doing his tests.
> 
> Mauro Carvalho Chehab (2):
>   [media] drxk_hard: fix the return code from an error handler
>   [media] xc4000: Fix a few warnings
> 
>  drivers/media/dvb-frontends/drxk_hard.c | 1 +
>  drivers/media/tuners/xc4000.c   | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)

-- 
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: coda: Fix H.264 header alignment.

[Philipp Zabel]

Hi Javier,

Am Montag, den 29.10.2012, 10:20 +0100 schrieb
javier.mar...@vista-silicon.com:
> From: Javier Martin 
> 
> Length of H.264 headers is variable and thus it might not be
> aligned for the coda to append the encoded frame. This causes
> the first frame to overwrite part of the H.264 PPS.
> 
> In order to solve that, a filler NAL must be added between
> the headers and the first frame to preserve alignment.

I can reproduce this, but CODA7/9 even need 64-bit alignment.

> Signed-off-by: Javier Martin 
> ---
>  drivers/media/platform/coda.c |   33 -
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index a8c7a94..4cdb4f4 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -177,6 +177,8 @@ struct coda_ctx {
>   int idx;
>  };
>  
> +static u8 coda_filler_nal[] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff, 0xff, 
> 0xff, 0xff, 0xff};
> +
>  static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg)
>  {
>   v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
> @@ -938,6 +940,29 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx, 
> struct coda_q_data *q_d
>   return 0;
>  }
>  
> +static int coda_h264_padding(int size, char *p)
> +{
> + int size_align = size & ~0x3;
> + int filler_size = ARRAY_SIZE(coda_filler_nal);
> + int nal_size;
> + int diff;
> +
> + diff = size - size_align;
> + if (diff == 0)
> + return 0;
> +
> + nal_size = filler_size + 2 - diff;
> + if (nal_size > filler_size)
> + nal_size -= 4;
> +
> + memcpy(p, coda_filler_nal, nal_size);
> +
> + /* Add rbsp stop bit and trailing at the end */
> + *(p + nal_size - 1) = 0x80;
> +
> + return nal_size;
> +}
> +
>  static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
>  {
>   struct coda_ctx *ctx = vb2_get_drv_priv(q);
> @@ -1165,7 +1190,13 @@ static int coda_start_streaming(struct vb2_queue *q, 
> unsigned int count)
>   coda_read(dev, CODA_CMD_ENC_HEADER_BB_START);
>   memcpy(&ctx->vpu_header[1][0], vb2_plane_vaddr(buf, 0),
>  ctx->vpu_header_size[1]);
> - ctx->vpu_header_size[2] = 0;
> + /*
> +  * Length of H.264 headers is variable and thus it might not be
> +  * aligned for the coda to append the encoded frame. In that is
> +  * the case a filler NAL must be added to header 2.
> +  */
> + ctx->vpu_header_size[2] = 
> coda_h264_padding((ctx->vpu_header_size[0] +
> + ctx->vpu_header_size[1]), 
> ctx->vpu_header[2]);
>   break;
>   case V4L2_PIX_FMT_MPEG4:
>   /*

regards
Philipp

--
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 0/2] Fix a few more warnings

[Mauro Carvalho Chehab]

Hans Verkuil yesterday's build still got two warnings at the
generic drivers:
http://hverkuil.home.xs4all.nl/logs/Sunday.log

They didn't appear at i386 build probably because of some
optimization done there.

Anyway, fixing them are trivial, so let's do it.

After applying those patches, the only drivers left producing
warnings are the following platform drivers:

drivers/media/platform/davinci/dm355_ccdc.c
drivers/media/platform/davinci/dm644x_ccdc.c
drivers/media/platform/davinci/vpbe_osd.c
drivers/media/platform/omap3isp/ispccdc.c
drivers/media/platform/omap3isp/isph3a_aewb.c
drivers/media/platform/omap3isp/isph3a_af.c
drivers/media/platform/omap3isp/isphist.c
drivers/media/platform/omap3isp/ispqueue.c
drivers/media/platform/omap3isp/ispvideo.c
drivers/media/platform/omap/omap_vout.c
drivers/media/platform/s5p-fimc/fimc-capture.c
drivers/media/platform/s5p-fimc/fimc-lite.c
drivers/media/platform/sh_vou.c
drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c

Platform driver maintainers: please fix, as those warnings could be
hiding real bugs. Also, removing all warnings is interesting,
as they helps to detect when new possible bugs got introduced.

I think Hans also use "make W=1" option when doing his tests.

Mauro Carvalho Chehab (2):
  [media] drxk_hard: fix the return code from an error handler
  [media] xc4000: Fix a few warnings

 drivers/media/dvb-frontends/drxk_hard.c | 1 +
 drivers/media/tuners/xc4000.c   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
1.7.11.7

--
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 2/2] [media] xc4000: Fix a few warnings

[Mauro Carvalho Chehab]

drivers/media/tuners/xc4000.c: In function ‘check_firmware’:
drivers/media/tuners/xc4000.c:1048:45: warning: ‘fw_minor’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/media/tuners/xc4000.c:1048:39: warning: ‘fw_major’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/media/tuners/xc4000.c:1062:39: warning: ‘hw_minor’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
drivers/media/tuners/xc4000.c:1062:33: warning: ‘hw_major’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/tuners/xc4000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/tuners/xc4000.c b/drivers/media/tuners/xc4000.c
index 4937712..5c0fd78 100644
--- a/drivers/media/tuners/xc4000.c
+++ b/drivers/media/tuners/xc4000.c
@@ -934,7 +934,7 @@ static int check_firmware(struct dvb_frontend *fe, unsigned 
int type,
intrc = 0, is_retry = 0;
u16hwmodel;
v4l2_std_idstd0;
-   u8 hw_major, hw_minor, fw_major, fw_minor;
+   u8 hw_major = 0, hw_minor = 0, fw_major = 0, 
fw_minor = 0;
 
dprintk(1, "%s called\n", __func__);
 
-- 
1.7.11.7

--
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 1/2] [media] drxk_hard: fix the return code from an error handler

[Mauro Carvalho Chehab]

While it is very unlikely, if the number of parameters for
QAMDemodulatorCommand is not 2 or 4, status become undefined:

/home/hans/work/build/v4l-dvb-git/drivers/media/dvb-frontends/drxk_hard.c: In 
function ‘QAMDemodulatorCommand’:
/home/hans/work/build/v4l-dvb-git/drivers/media/dvb-frontends/drxk_hard.c:5452:5:
 warning: ‘status’ may be used uninitialized in this function [-Wuninitialized]

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/drxk_hard.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/dvb-frontends/drxk_hard.c 
b/drivers/media/dvb-frontends/drxk_hard.c
index 59382fb..76a4e5c 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -5446,6 +5446,7 @@ static int QAMDemodulatorCommand(struct drxk_state *state,
} else {
printk(KERN_WARNING "drxk: Unknown QAM demodulator parameter "
"count %d\n", numberOfParameters);
+   status = -EINVAL;
}
 
 error:
-- 
1.7.11.7

--
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: coda: Fix H.264 header alignment.

[javier . martin]

From: Javier Martin 

Length of H.264 headers is variable and thus it might not be
aligned for the coda to append the encoded frame. This causes
the first frame to overwrite part of the H.264 PPS.

In order to solve that, a filler NAL must be added between
the headers and the first frame to preserve alignment.

Signed-off-by: Javier Martin 
---
 drivers/media/platform/coda.c |   33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index a8c7a94..4cdb4f4 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -177,6 +177,8 @@ struct coda_ctx {
int idx;
 };
 
+static u8 coda_filler_nal[] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff, 0xff, 
0xff, 0xff, 0xff};
+
 static inline void coda_write(struct coda_dev *dev, u32 data, u32 reg)
 {
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
@@ -938,6 +940,29 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx, 
struct coda_q_data *q_d
return 0;
 }
 
+static int coda_h264_padding(int size, char *p)
+{
+   int size_align = size & ~0x3;
+   int filler_size = ARRAY_SIZE(coda_filler_nal);
+   int nal_size;
+   int diff;
+
+   diff = size - size_align;
+   if (diff == 0)
+   return 0;
+
+   nal_size = filler_size + 2 - diff;
+   if (nal_size > filler_size)
+   nal_size -= 4;
+
+   memcpy(p, coda_filler_nal, nal_size);
+
+   /* Add rbsp stop bit and trailing at the end */
+   *(p + nal_size - 1) = 0x80;
+
+   return nal_size;
+}
+
 static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
 {
struct coda_ctx *ctx = vb2_get_drv_priv(q);
@@ -1165,7 +1190,13 @@ static int coda_start_streaming(struct vb2_queue *q, 
unsigned int count)
coda_read(dev, CODA_CMD_ENC_HEADER_BB_START);
memcpy(&ctx->vpu_header[1][0], vb2_plane_vaddr(buf, 0),
   ctx->vpu_header_size[1]);
-   ctx->vpu_header_size[2] = 0;
+   /*
+* Length of H.264 headers is variable and thus it might not be
+* aligned for the coda to append the encoded frame. In that is
+* the case a filler NAL must be added to header 2.
+*/
+   ctx->vpu_header_size[2] = 
coda_h264_padding((ctx->vpu_header_size[0] +
+   ctx->vpu_header_size[1]), 
ctx->vpu_header[2]);
break;
case V4L2_PIX_FMT_MPEG4:
/*
-- 
1.7.9.5

--
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

[PATCHv2] Improve media Kconfig menu

[Hans Verkuil]

(Sent again, this time with a SoB)

I've always found it very confusing that the "Media ancillary drivers (tuners,
sensors, i2c, frontends)" comment came after the "Autoselect" option. This patch
moves it up and changes the "Autoselect" text to correspond more closely to
the "Media ancillary drivers" comment.

It also fixes two typos.

Signed-off-by: Hans Verkuil 

Regards,

Hans

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 4ef0d80..9fbfb94 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -158,17 +158,20 @@ source "drivers/media/firewire/Kconfig"
 # Common driver options
 source "drivers/media/common/Kconfig"
 
+comment "Media ancillary drivers (tuners, sensors, i2c, frontends)"
+
 #
 # Ancillary drivers (tuners, i2c, frontends)
 #
 
 config MEDIA_SUBDRV_AUTOSELECT
-   bool "Autoselect tuners and i2c modules to build"
+   bool "Autoselect ancillary drivers (tuners, sensors, i2c, frontends)"
depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
MEDIA_CAMERA_SUPPORT
default y
help
- By default, a media driver auto-selects all possible i2c
- devices that are used by any of the supported devices.
+ By default, a media driver auto-selects all possible ancillary
+ devices such as tuners, sensors, video encoders/decoders and
+ frontends, that are used by any of the supported devices.
 
  This is generally the right thing to do, except when there
  are strict constraints with regards to the kernel size,
@@ -177,12 +180,10 @@ config MEDIA_SUBDRV_AUTOSELECT
  Use this option with care, as deselecting ancillary drivers which
  are, in fact, necessary will result in the lack of the needed
  functionality for your device (it may not tune or may not have
- the need demodulers).
+ the needed demodulators).
 
  If unsure say Y.
 
-comment "Media ancillary drivers (tuners, sensors, i2c, frontends)"
-
 source "drivers/media/i2c/Kconfig"
 source "drivers/media/tuners/Kconfig"
 source "drivers/media/dvb-frontends/Kconfig"
--
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 2/2] media: V4L2: support asynchronous subdevice registration

[Guennadi Liakhovetski]

On Sun, 28 Oct 2012, Sylwester Nawrocki wrote:

> Hi,
> 
> On 10/24/2012 03:54 PM, Guennadi Liakhovetski wrote:
> > On Sat, 20 Oct 2012, Guennadi Liakhovetski wrote:
> > 
> >> Currently bridge device drivers register devices for all subdevices
> >> synchronously, tupically, during their probing. E.g. if an I2C CMOS sensor
> >> is attached to a video bridge device, the bridge driver will create an I2C
> >> device and wait for the respective I2C driver to probe. This makes linking
> >> of devices straight forward, but this approach cannot be used with
> >> intrinsically asynchronous and unordered device registration systems like
> >> the Flattened Device Tree. To support such systems this patch adds an
> >> asynchronous subdevice registration framework to V4L2. To use it respective
> >> (e.g. I2C) subdevice drivers must request deferred probing as long as their
> >> bridge driver hasn't probed. The bridge driver during its probing submits a
> >> an arbitrary number of subdevice descriptor groups to the framework to
> >> manage. After that it can add callbacks to each of those groups to be
> >> called at various stages during subdevice probing, e.g. after completion.
> >> Then the bridge driver can request single groups to be probed, finish its
> >> own probing and continue its video subsystem configuration from its
> >> callbacks.
> >>
> >> Signed-off-by: Guennadi Liakhovetski
> > 
> > Sorry, I did indeed forget to include you on CC for this patch as promised
> > in https://lkml.org/lkml/2012/10/17/306. In the patch below just look for
> > the only occurrance of the device_release_driver() / device_attach(). In
> > your mail you said, that only bus drivers should do this. In fact this is
> > indeed what is happening here. A device is attached to two busses:
> > (typically) I2C and "media." And the code below is called when the device
> > is detached from the media bus.
> > 
> > Thanks
> > Guennadi
> > 
> >> ---
> >>
> >> One more thing to note about this patch. Subdevice drivers, supporting
> >> asynchronous probing, and using this framework, need a unified way to
> >> detect, whether their probing should succeed or they should request
> >> deferred probing. I implement this using device platform data. This means,
> >> that all subdevice drivers, wishing to use this API will have to use the
> >> same platform data struct. I don't think this is a major inconvenience,
> >> but if we decide against this, we'll have to add a V4L2 function to verify
> >> "are you ready for me or not." The latter would be inconvenient, because
> >> then we would have to look through all registered subdevice descriptor
> >> groups for this specific subdevice.
> >>
> >>   drivers/media/v4l2-core/Makefile  |3 +-
> >>   drivers/media/v4l2-core/v4l2-async.c  |  249 
> >> +
> >>   drivers/media/v4l2-core/v4l2-device.c |2 +
> >>   include/media/v4l2-async.h|   88 
> >>   include/media/v4l2-device.h   |6 +
> >>   include/media/v4l2-subdev.h   |   16 ++
> >>   6 files changed, 363 insertions(+), 1 deletions(-)
> >>   create mode 100644 drivers/media/v4l2-core/v4l2-async.c
> >>   create mode 100644 include/media/v4l2-async.h
> >>
> >> diff --git a/drivers/media/v4l2-core/Makefile 
> >> b/drivers/media/v4l2-core/Makefile
> >> index cb5fede..074e01c 100644
> >> --- a/drivers/media/v4l2-core/Makefile
> >> +++ b/drivers/media/v4l2-core/Makefile
> >> @@ -5,7 +5,8 @@
> >>   tuner-objs   :=  tuner-core.o
> >>
> >>   videodev-objs:=  v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o 
> >> \
> >> -  v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o
> >> +  v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> >> +  v4l2-async.o
> >>   ifeq ($(CONFIG_COMPAT),y)
> >> videodev-objs += v4l2-compat-ioctl32.o
> >>   endif
> >> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> >> b/drivers/media/v4l2-core/v4l2-async.c
> >> new file mode 100644
> >> index 000..871f116
> >> --- /dev/null
> >> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >> @@ -0,0 +1,249 @@
> >> +/*
> >> + * V4L2 asynchronous subdevice registration API
> >> + *
> >> + * Copyright (C) 2012, Guennadi Liakhovetski
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +static bool match_i2c(struct device *dev, struct v4l2_async_hw_device 
> >> *hw_dev)
> >> +{
> >> +  struct i2c_client *client = to_i2c_client(dev);
> >> +  return hw_dev->bus_type == V4L2_ASYNC_BUS_I2C&&
> >> +  hw_dev->match.i2c.adapter_id == client->adapter->nr&&
> >> +