bttv port from v4l1 to v4l2

[gnome42@…]

NOTE: I have modified my version of myth to use V4L2 instead of V4L1 with my bttv cards. I submit this patch in preparation for when V4L1 goes away, and for review etc.

Semi-regularily the bttv driver has a shit-fit. Luckily, for the last couple of years the bttv driver has been capable of reseting and recovering nicely in this situation. Mythtv usually doesn't handle this very well. I have experienced these errors with many flavours of bttv cards and mobos over the years:

System log:

kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR*
kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR*
kernel: bttv0: SCERR @ 1f66c014,bits: HSYNC OFLOW SCERR*
last message repeated 15 times
kernel: bttv0: timeout: drop=5 irq=556586/556586, risc=1f66c01c, bits: HSYNC OFLOW
kernel: bttv0: reset, reinitialize
kernel: bttv0: PLL can sleep, using XTAL (28636363).
kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR*

This results in EIO when dequeing the video buffers from V4L2, (This example is with my patch applied and shows a successful recovery):

Mythbackend log:

2006-07-17 18:21:41.509 XDS: Unhandled packet (0x2 0x2) sz(20) ''
2006-07-17 18:21:42.320 NVR(/dev/video0) Error: Reading VBI data
                        eno: Input/output error (5)
2006-07-17 18:21:42.396 NVR(/dev/video0) Error: Reading VBI data
                        eno: Input/output error (5)
VIDIOC_DQBUF: Input/output error
2006-07-17 18:21:42.411 NVR(/dev/video0) Error: Reading VBI data
                        eno: Input/output error (5)
2006-07-17 18:21:42.413 NVR(/dev/video0): Reset and requeue capture buffers.
2006-07-17 18:21:42.415 NVR(/dev/video0) Error: Reading VBI data
                        eno: Input/output error (5)
2006-07-17 18:23:01.123 XDS: Unhandled packet (0x2 0x2) sz(26) ''
2006-07-17 18:27:24.431 MainServer::HandleAnnounce Monitor
2006-07-17 18:27:24.489 adding: mars as a client (events: 0)

Without this patch I usually need to restart the backend, and miss the intervening shows etc., in order to fully recover.

What this patch does:

• Resets and requeues the V4L2 video capture buffers when we get and EIO error. We have to do this because there is no way to know what state the video buffer we just tried to dequeue is in.

• Consolidates the existing reset/requeue buffer code. Needs testing by go7007 user.

• Changes -EINVAL to EINVAL. I get a positive EIO so I assume we get a positive EINVAL too but, I never got one in my testing so I couldn't verify.

• Removes goto label which is at the top of the while loop.

Shane

[gnome42@…]

V4L2 capture buffer reset

[danielk]

(In [11416]) Fixes #2073. This extends support for recovery from a EINVAL or EIO to v4l2 drivers other than the go7007 using modified patch from gnome42 at gmail.

When the bttv v4l2 driver freaks it errors with one of these and you need to reset the buffer state to continue, we already had the code to do this with the go7007 so this just employs this for all v4l2 drivers. This is a safe API call for all v4l2 drivers and is recommended practice anyway. The reset also appears to help when the cx88 freaks out on channel changes (by dropping most of the damaged frames, we still need the retune hack for this driver when we get an EIO).

This does not do a reset on file changes for any drivers other than the go7007, it only does the buffer reset on errors for normal V4L2 devices.

(I removed the cosmetic fixes in the patch to make reading the changeset easier).