aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/usb
Commit message (Collapse)AuthorAge
...
| * | [media] em28xx: autoload em28xx-rc if the device has an I2C IRMauro Carvalho Chehab2013-01-04
| | | | | | | | | | | | | | | | | | | | | | | | If the device has an I2C IR, em28xx-rc should be loaded by default, except if the user explicitly requested to not load, via modprobe option. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: initialize button/I2C IR earlierMauro Carvalho Chehab2013-01-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The em28xx-input is used by 3 different types of input devices: - devices with buttons (like cameras and grabber devices); - devices with I2C remotes; - em2860 or latter chips with RC support embedded. When the device has an I2C remote, all it needs to do is to call the proper I2C driver (ir-i2c-kbd), passing the proper data to it, and just leave the code. Also, button devices have its own init code that doesn't depend on having an IR or not (as a general rule, they don't have). So, move its init code to fix bugs introduced by earlier patches that prevent them to work. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] lmedm04: correct I2C values to 7 bit addressingMalcolm Priestley2013-01-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The separation the lmedm04 fails on the ts2020 portion because the correct I2C addressing. So, it's time to correct the addressing in the remainder of lmedm04. Tested all tuners. Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] stk1160: Replace BUG_ON with WARN_ONEzequiel Garcia2013-01-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | This situation is not even an error condition so it's stupid to BUG_ON. Learn the lesson: http://permalink.gmane.org/gmane.linux.kernel/1347333 Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m88rs2000: make use ts2020Igor M. Liplianin2012-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tuner part of Montage rs2000 chip is similar to ts2020 tuner. Patch to use ts2020 code. [mchehab@redhat.com: a few CodingStyle fixes] Signed-off-by: Igor M. Liplianin <liplianin@me.by> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] ds3000: lock led procedure addedIgor M. Liplianin2012-12-28
| | | | | | | | | | | | | | | | | | | | | | | | TeVii s660 and others have LED for lock indication. Let's use it in right order. Signed-off-by: Igor M. Liplianin <liplianin@me.by> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] dw2102: autoselect DVB_M88RS2000Igor M. Liplianin2012-12-28
| | | | | | | | | | | | | | | | | | | | | | | | Patch to select rs2000 module to compile automatically for TeVii S421 and S632 cards. Signed-off-by: Igor M. Liplianin <liplianin@me.by> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] TeVii DVB-S s421 and s632 cards supportIgor M. Liplianin2012-12-27
| | | | | | | | | | | | | | | | | | | | | DVB-S chip is Montage m88rs2000, so initial patch is simple. Signed-off-by: Igor M. Liplianin <liplianin@me.by> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: rename module parameter prefer_bulk to usb_xfer_modeFrank Schaefer2012-12-27
| | | | | | | | | | | | | | | | | | | | | Since we have now 3 modes (auto/isoc/bulk), usb_xfer_mode is more suitable than prefer_bulk. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] make the other drivers take use of the new ts2020 driverKonstantin Dimitrov2012-12-27
| | | | | | | | | | | | | | | | | | | | | make the other drivers take use of the separate ts2020 driver Signed-off-by: Konstantin Dimitrov <kosio.dimitrov@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] it913x: add support for Avermedia A835BEddi De Pieri2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | Add support for Avermedia A835B and variants. Signed-off-by: Eddi De Pieri <eddi@depieri.net> Cc: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] au0828: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] dvb-usb/friio-fe: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] hdpvr: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] pvrusb2: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] pwc: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] sn9c102: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] usbvision: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] cx231xx: Replace memcpy with struct assignmentEzequiel Garcia2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This kind of memcpy() is error-prone. Its replacement with a struct assignment is prefered because it's type-safe and much easier to read. Found by coccinelle. Hand patched and reviewed. Tested by compilation only. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier struct_name; struct struct_name to; struct struct_name from; expression E; @@ -memcpy(&(to), &(from), E); +to = from; // </smpl> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com> Signed-off-by: Ezequiel Garcia <elezegarcia@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: add support for the VP-7049 Twinhan DVB-T USB StickAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This device was originally made by Twinhan/Azurewave[1] and sometimes named DTV-DVB UDTT7049, it could be also found in Italy under the name of Digicom Digitune-S[2], or Think Xtra Hollywood DVB-T USB2.0[3]. Components: Usb bridge: ULi M9206 Frontend: MT352CG Tuner: MT2060F The firmware can be downloaded with: $ ./Documentation/dvb/get_dvb_firmware vp7049 [1] http://www.azurewave.com/Support_Utility_Driver.asp [2] http://www.digicom.it/digisit/driver_link.nsf/driverprodotto?openform&prodotto=DigiTuneS [3] http://www.txitalia.it/prodotto.asp?prodotto=txhollywooddvttv Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: send the RC init sequence also when rc.core is usedAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: Fix CodingStyle issuesMauro Carvalho Chehab2012-12-27
| | | | | | | | | | | | | | | | | | Fix CodingStyle issues introduced by the last patch Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: introduce m920x_rc_core_query()Antonio Ospite2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | Add an m920x_rc_core_query() function for drivers which want to use the linux RC core infrastructure. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: avoid repeating RC state parsing at each keycodeAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | Parsing the RC press state is invariant wrt. the keycode, take it out of the keycode scanning loop. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: factor out a m920x_parse_rc_state() functionAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is in preparation to using RC core infrastructure for some devices, the RC button state parsing logic can be shared berween rc.legacy and rc.core callbacks as it is independent from the mechanism used for RC handling. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: factor out a m920x_write_seq() functionAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | This is in preparation for the vp7049 frontend attach function which is going to set a sequence of registers as well. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] m920x: fix a typo in a commentAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] dvb-usb: fix indentation of a for loopAntonio Ospite2012-12-27
| | | | | | | | | | | | | | | Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] cx231xx : Add support for Elgato Video Capture V2Alf Høgemark2012-12-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the Elgato Video Capture, version 2, device. The device is added based on the code for CX231XX_BOARD_HAUPPAUGE_USBLIVE2, it is simply a copy of the code for that board, with the proper USB device info for the Elgato Video Capture V2 device. Signed-off-by: Alf Høgemark <alf@i100.no> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] it913x: fix correct endpoint size when pid filter onMalcolm Priestley2012-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I kept the count as the hardware default with dvb-usb-v2, with 5, users can still run in to trouble with Video PIDs. I have traced it to an incorrect endpoint size when the PID filter is enabled. It also affected USB 2.0 with the filter on. Reported-by: Antti Palosaari <crope@iki.fi> Tested-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: prefer bulk mode on webcamsMauro Carvalho Chehab2012-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using bulk mode allows more than one webcam, as the maximum fps is low at 640x480 resolution. So, prefer it, if the device is a webcam. Tested with Silvercrest 1.3 Mpixel webcam (em2710) on both bulk and isoc modes. Tested analog with HVR-950 model 65201/A1C0 (em2883), where only ISOC endpoints are available for both DVB and Analog. Tested on Hauppauge WinTV USB 2 (em2840) on both bulk and isoc modes. It should be noticed that enabling bulk mode by default with TV boards is a bad idea; what happens is that, while with ISOC the USB logic will prevent the concurrent usage of two devices that spends more than 100% of the USB2 traffic, it doesn't care with bulk transfers. On my tests, I started two streams, one with a WinTV at 640x480x30fps and the other one with a Silvercrest webcam at 640x480, on a lower fps) both on bulk mode. One of the streams always silently failed. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: make the logs reflect the specific chip nameMauro Carvalho Chehab2012-12-23
| | | | | | | | | | | | | | | | | | | | | | | | In order to make easier to analize the logs when multiple devices are plugged, change the device name accordingly with the chip version. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: display the isoc/bulk modeMauro Carvalho Chehab2012-12-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As both bulk and isoc modes can be available, display what it was found for both DVB and analog. While here, also displays if audio is provided via USB Audio Class or via vendor's extension. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: prefer_bulk parameter is read-onlyMauro Carvalho Chehab2012-12-23
| | | | | | | | | | | | | | | | | | | | | | | | As the bulk mode is set at device's probe, it is not possible to change it later. So, change the parameter to be read only after modprobing. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: clean up the data type mess of the i2c transfer function ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | parameters Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: clean up and unify functions em28xx_copy_vbi() ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | em28xx_copy_video() The code in em28xx_vbi_copy can be simplified a lot. Also rename some variables to something more meaningful and fix+add the function descriptions. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: move the em2710/em2750/em28xx specific frame data processing ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | code to a separate function em28xx_urb_data_copy() actually consists of two parts: USB urb processing (checks, data extraction) and frame data packet processing. Move the latter to a separate function and call it from em28xx_urb_data_copy() for each data packet. The em25xx, em2760, em2765 (and likely em277x) chip variants are using a different frame data format, for which support will be added later with another function. This reduces the size of em28xx_urb_data_copy() and makes the code much more readable. While we're at it, clean up the code a bit (rename some variables to something more meaningful, improve some comments etc.) Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: em28xx_urb_data_copy(): move duplicate code for ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | capture_type=0 and capture_type=2 to a function Reduce code duplication by moving the duplicate code for dev->capture_type=0 (vbi start) and dev->capture_type=2 (video start) to a function. The same function will also be called by the (not yet existing) em25xx frame data processing code. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: move caching of pointer to vmalloc memory in videobuf to ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | struct em28xx_buffer In the current code em28xx_urb_data_copy() caches the pointer to the vmalloc memory in videobuf locally. The alternative would be to call videobuf_to_vmalloc() for each processed USB data packet (isoc USB transfers => 64 times per URB) in the em28xx_copy_*() functions. With the next commits, the data processing code will be split into functions for serveral reasons: - em28xx_urb_data_copy() is generally way to long, making it less readable - there is code duplication between VBI and video data processing - support for em25xx data processing (uses a different header and frame end signaling mechanism) will be added This would require extensive usage of pointer-pointers, which usually makes the code less readable and prone to bugs. The better solution is to cache the pointer in struct em28xx_buffer. This also improves consistency, because we already track the buffer fill count there. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: refactor VBI data processing code in em28xx_urb_data_copy()Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a new frame header is detected in em28xx_urb_data_copy() and the data packet contains both, VBI data and video data, the prevoius VBI buffer doesn't get finished and is overwritten with the new VBI data. This bug is not triggered with isochronous USB transfers, because the data packetes are much smaller than the VBI data size. But when using USB bulk transfers, the whole data of an URB is treated as single packet, which is usually much larger then the VBI data size. Refactor the VBI data processing code to fix this bug, but also to simplify the code and make it similar to the video data processing code part (which allows further code abstraction/unification in the future). The changes have been tested with device "Hauppauge HVR-900". Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: move field 'pos' from struct em28xx_dmaqueue to struct ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | em28xx_buffer This field is used to keep track of the current memory position in the buffer, not in the dma queue, so move it to right place. This also allows us to get rid of the struct em28xx_dmaqueue pointer parameter in functions em28xx_copy_video() and em28xx_copy_vbi(). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: remove obsolete field 'frame' from struct em28xx_bufferFrank Schaefer2012-12-22
| | | | | | | | | | | | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: use common function for video and vbi buffer completionFrank Schaefer2012-12-22
| | | | | | | | | | | | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: refactor get_next_buf() and use it for vbi data, tooFrank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | get_next_buf() and vbi_get_next_buf() do exactly the same just with a different dma queue and buffer. Saving the new buffer pointer back to the device struct in em28xx_urb_data_copy() instead of doing this from inside these functions makes it possible to get rid of one of them. Also refactor the function parameters and return type: - pass a pointer to struct em28xx as parameter (instead of obtaining the pointer from the dma queue pointer with the container_of macro) like we do it in all other functions - instead of using a pointer-pointer, return the pointer to the new buffer as return value of the function Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: use common urb data copying function for vbi and non-vbi ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | data streams em28xx_urb_data_copy_vbi() is actually an extended version of em28xx_urb_data_copy(). With the preceding fixes and improvements, it works fine with both, vbi and non-vbi data streams without performance impacts. So rename em28xx_urb_data_copy_vbi() to em28xx_urb_data_copy(), delete the the old implementation of em28xx_urb_data_copy() and change the code to use this function for both data stream types. Tested with "SilverCrest 1.3 MPix webcam" (progressive, non-vbi) and "Hauppauge HVR-900 (65008/A1C0)" (interlaced, vbi enabled and disabled). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: em28xx_urb_data_copy_vbi(): calculate vbi_size only if neededFrank Schaefer2012-12-22
| | | | | | | | | | | | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: fix capture type setting in em28xx_urb_data_copy_vbi()Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set capture type to 1 (video start) when the video frame start header is detected. This bug didn't cause any trouble, because this type of header is never received in vbi mode. Fix it, because we want to use this function with disabled vbi in the future. Also start with capture type -1 to avoid processing of corrupted/incomplete frame data which is usually received at streaming start (especially when USB bulk transfers are used). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: make sure the packet size is >= 4 before checking for ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | headers in em28xx_urb_data_copy_vbi() Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: fix video data start position calculation in ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | em28xx_urb_data_copy_vbi() The header check/removal code at the end of function em28xx_urb_data_copy_vbi() is obsolete, because this is already done earlier in this function. In fact it is incomplete (doesn't check for vbi header) and causes trouble when the first data bytes are the same as header bytes (which is fortunately very unlikely). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
| * | [media] em28xx: add module parameter for selection of the preferred USB ↵Frank Schaefer2012-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | transfer type By default, isoc transfers are used if possible. With the new module parameter, bulk can be selected as the preferred USB transfer type. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-10 03:20:16 -0400