Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The ir-i2c-kbd already adds I2C IR before the name. The way it is,
the devices are named as:
	"i2c IR (i2c IR (EM2840 Hauppaug"
With is ugly and incorrect. After this patch, it is now properly
displayed as:
	"i2c IR (WinTV USB2)"
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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/1347333Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NIgor M. Liplianin <liplianin@me.by>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

TeVii s660 and others have LED for lock indication.
Let's use it in right order.
Signed-off-by: NIgor M. Liplianin <liplianin@me.by>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Patch to select rs2000 module to compile automatically for TeVii
S421 and S632 cards.
Signed-off-by: NIgor M. Liplianin <liplianin@me.by>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

DVB-S chip is Montage m88rs2000, so initial patch is simple.
Signed-off-by: NIgor M. Liplianin <liplianin@me.by>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Since we have now 3 modes (auto/isoc/bulk), usb_xfer_mode is more suitable than prefer_bulk.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

make the other drivers take use of the separate ts2020 driver
Signed-off-by: NKonstantin Dimitrov <kosio.dimitrov@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for Avermedia A835B and variants.
Signed-off-by: NEddi De Pieri <eddi@depieri.net>
Cc: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NPeter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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=txhollywooddvttvSigned-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix CodingStyle issues introduced by the last patch
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add an m920x_rc_core_query() function for drivers which want to use the
linux RC core infrastructure.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Parsing the RC press state is invariant wrt. the keycode, take it out of
the keycode scanning loop.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is in preparation for the vp7049 frontend attach function which is
going to set a sequence of registers as well.
Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NAlf Høgemark <alf@i100.no>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NAntti Palosaari <crope@iki.fi>
Tested-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[media] em28xx: move the em2710/em2750/em28xx specific frame data processing 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: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>