kernel.git/drivers/media/video, branch linux-2.6.37.y

uvcvideo: Fix descriptor parsing for video output devices

2011-03-27T19:00:23Z

commit 4093a5c4a3f59cba1a085bbf87b6ffdddc5a443d upstream. Commit 4057ac6ca9a77c4275b34b5925ab5c99557913b1 V4L/DVB (13505): uvcvideo: Refactor chain scan broke output terminals parsing. Fix it. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

uvcvideo: Fix uvc_fixup_video_ctrl() format search

2011-03-27T19:00:22Z

commit 38a66824d96de8aeeb915e6f46f0d3fe55828eb1 upstream. The scheme used to index format in uvc_fixup_video_ctrl() is not robust: format index is based on descriptor ordering, which does not necessarily match bFormatIndex ordering. Searching for first matching format will prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make adjustments. Signed-off-by: Stephan Lachowsky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

cx25840: fix probing of cx2583x chips

2011-03-14T21:17:41Z

commit 1e6406b8f0dc1ae7d7c39c9e1ac6ca78e016ebfb upstream. Fix the probing of cx2583x chips, because two controls were clustered that are not created for these chips. This regression was introduced in 2.6.36. Signed-off-by: Sven Barth Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

cx23885: Revert "Check for slave nack on all transactions"

2011-03-14T21:17:40Z

commit 67914b5c400d6c213f9e56d7547a2038ab5c06f4 upstream. This reverts commit 44835f197bf1e3f57464f23dfb239fef06cf89be. With the CX23885 hardware I2C master, checking for I2C slave ACK/NAK is not valid when the I2C_EXTEND or I2C_NOSTOP bits are set. Revert the commit that checks for I2C slave ACK/NAK on all transactions, so that XC5000 tuners work with the CX23885 again. Thanks go to Mark Zimmerman for reporting and bisecting this problem. Bisected-by: Mark Zimmerman Reported-by: Mark Zimmerman Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang

2011-03-14T21:17:40Z

commit d213ad08362909ab50fbd6568fcc9fd568268d29 upstream. After upgrading the kernel from stock Ubuntu 7.10 to 10.04, with no hardware changes, I started getting the dreaded DMA TIMEOUT errors, followed by inability to encode until the machine was rebooted. I came across a post from Andy in March (http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he speculates that perhaps the corrective actions being taken after a DMA ERROR are not sufficient to recover the situation. After some testing I suspect that this is indeed the case, and that in fact the corrective action may be what hangs the card's DMA engine, rather than the original error. Specifically these DMA ERROR IRQs seem to present with two different values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current corrective action is to clear that status register back to 0x01 or 0x03, and then issue the next DMA request. In the case of a 0x13 this seems to result in a minor glitch in the encoded stream due to the failed transfer that was not retried, but otherwise things continue OK. In the case of a 0x11 the card's DMA write engine is never heard from again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer. I suspect that the two cases need to be handled differently. The difference is in bit 1 (0x02), which is set when the error is about to be successfully recovered, and clear when things are about to go bad. Bit 1 of DMASTATUS is described differently in different places either as a positive "write finished", or an inverted "write busy". If we take the first definition, then when an error arises with state 0x11, it means that the write did not complete. It makes sense to start a new transfer, as in the current code. But if we take the second definition, then 0x11 means "an error but the write engine is still busy". Trying to feed it a new transfer in this situation might not be a good idea. As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS is 0x11. I.e., don't start a new transfer, don't clear our flags, etc. The hope was that the card would complete the transfer and issue a ENC DMA COMPLETE, either successfully or with an error condition there. However the card still hung. The only remaining corrective action being taken with a 0x11 status was then the write back to the status register to clear the error, i.e. DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the error bit 4, while leaving the lower bits indicating DMA write busy. Strangely enough, removing this write to the status register solved the problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely ignored, with no corrective action at all, then the card will complete the transfer and issue a new IRQ. If the status register is written to when it has the value 0x11, then the DMA engine hangs. Perhaps it's illegal to write to DMASTATUS while the read or write busy bit is set? At any rate, it appears that the current corrective action is indeed making things worse rather than better. I put together a patch that modifies ivtv_irq_dma_err to do the following: - Don't write back to IVTV_REG_DMASTATUS. - If write-busy is asserted, leave the card alone. Just extend the timeout slightly. - If write-busy is de-asserted, retry the current transfer. This has completely fixed my DMA TIMEOUT woes. DMA ERR events still occur, but now they seem to be correctly handled. 0x11 events no longer hang the card, and 0x13 events no longer result in a glitch in the stream, as the failed transfer is retried. I'm happy. I've inlined the patch below in case it is of interest. As described above, I have a theory about why it works (based on a different interpretation of bit 1 of DMASTATUS), but I can't guarantee that my theory is correct. There may be another explanation, or it may be a fluke. Maybe ignoring that IRQ entirely would be equally effective? Maybe the status register read/writeback sequence is race condition if the card changes it in the mean time? Also as I am using a PVR-150 only, I have not been able to test it on other cards, which may be especially relevant for 350s that support concurrent decoding. Hopefully the patch does not break the DMA READ path. Mike [awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both read and write DMA were not in progress. Mike's conjecture about a race condition with the writeback is correct; it can confuse the DMA engine.] [Comment and analysis from the ML post by Michael ] Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

em28xx: Fix audio input for Terratec Grabby

2011-02-17T23:14:03Z

commit a3fa904ec79b94f0db7faed010ff94d42f7d1d47 upstream. The audio input line was wrong. Fix it. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman

[media] em28xx: radio_fops should also use unlocked_ioctl

2011-01-03T11:52:25Z

em28xx uses core assisted locking, so it shouldn't use .ioctl. The .ioctl callback was replaced by .unlocked_ioctl for video nodes, but not for radio nodes. This is now corrected. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

[media] wm8775: Revert changeset fcb9757333 to avoid a regression

2011-01-03T11:09:56Z

It seems that cx88 and ivtv use wm8775 on some different modes. The patch that added support for a board with wm8775 broke ivtv boards with this device. As we're too close to release 2.6.37, let's just revert it. Reported-by: Andy Walls Reported-by: Eric Sharkey Reported-by: Auric Reported by: David Gesswein Signed-off-by: Mauro Carvalho Chehab

[media] cx25840: Prevent device probe failure due to volume control ERANGE error

2011-01-03T11:08:16Z

This patch fixes a regression that crept into 2.6.36. The volume control scale in the cx25840 driver has an unusual mapping from register values to v4l2 volume control values. Enforce the mapping limits, so that the default volume control setting does not fall out of bounds to prevent the cx25840 module device probe from failing. Signed-off-by: Andy Walls Cc: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6

2010-12-28T19:23:30Z

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: [media] v4l: soc-camera: fix multiple simultaneous user case