Add support for the remote control that comes with the Cinergy Hybrid T USB XS

Thanks to Jelle de Jong for providing sample hardware to test with.

Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: NDevin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixed eeprom hash table
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx: Add support for Gadmei UTV330+
Signed-off-by: NZhenyu Wang <zhen78@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We should call em28xx_ir_init(dev) only when disable_ir is true.
Signed-off-by: NShine Liu <shinel@foxmail.com>
Reviewed-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[mchehab@redhat.com: fix merge conflict and a few CodingStyle issues]
Signed-off-by: NSteve Gotthardt <gotthardt@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Register 0x13 seems to be a sort of image control, maybe gamma, white
level or black level. Lower values produce better images, while higher
values increases the contrast and shifts colors to green. 0xff produces
a black image. This register is not Silvercrest-specific, so its code
should be moved to a better place.

If this register is left alone, a random value can be found at the
register, producing weird results.

While here, let's remove register 0x0d, as it had no noticed effect at
the image.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Silvercrest mt9v011 sensor produces a 640x480 image. However,
previously, the code were getting only half of the lines and merging two
consecutive frames to "produce" a 640x480 image.

With the addition of progressive mode, now em28xx is working with a full
image. However, when the number of lines is bigger than 240, the
beginning of some odd lines are filled with blank.

After lots of testing, and physically checking the device for a Xtal, it
was noticed experimentally that mt9v011 is using em28xx XCLK as its
clock. Due to that, changing XCLK value changes the maximum speed of the
stream.

At the tests, it were possible to produce up to 32 fps, using a 30 MHz
XCLK. However, at that rate, the artifacts happen even at 320x240. Lower
values of XCLK produces artifacts only at 640x480.

At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is
possible to see an invalid sucession of artifacts with this pattern:

.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

(where the dots represent the blanked pixels)

So, it seems that a waveform in the format of a ramp is interferring at
the image.

The cause of this interference is currently unknown. Some possibilities
are:
	- electrical interference (maybe this device is broken?);
	- some issue at mt9v011 programming;
	- some bug at em28xx chip.

So, for now, let's be conservative and use a value of XCLK that we know
for sure that it won't cause artifacts.

As I'm waiting for more of such devices with different em28xx chipset
revisions, I'll have the opportunity to double check the issue with
other pieces of hardware.

Later patches can vary XCLK depending on the vertical resolutions, if a
proper fix is not discovered.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx_pre_card_setup() is meant to contain board-specific initialization. Also,
as autodetection sometimes occur only after having i2c bus enabled, this
function may need to be called later.

Moving those setups to happen outside the function avoids calling it twice without
need and without duplicating output lines at dmesg.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We don't know the xtal frequency of Silvercrest, but we need to have
some value in order to allow controlling the frame rate frequency. The
value is probably still wrong, since the manufacturer announces this
device as being capable of 30fps, but the maximum we can get is
13.5 fps.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Due to historical reasons, em28xx driver gets two consecutive frames and
fold them into an unique framing, doing interlacing. While this works
fine for TV images, this produces two bad effects with webcams:

1) webcam images are progressive. Merging two consecutive images produce
interlacing artifacts on the image;

2) since the driver needs to get two frames, it reduces the maximum
frame rate by two.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

As reported by hermann pitton <hermann-pitton@arcor.de>, some devices
has a different chip id for em2710 (likely the older ones):

em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0)
em28xx #0: Identified as EM2710/EM2750/EM2751 webcam grabber (card=22)
em28xx #0: em28xx chip ID = 17
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to hermann pitton <hermann-pitton@arcor.de> for pointing this new
variation.
Tested-by: Nhermann pitton <hermann-pitton@arcor.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This device uses msp34xx and uses 2.048 MHz frequency for I2S
communication.

Thanks to Angelo Cano <acano@fastmail.fm> for pointing the issues with
this device and proposing an approach for fixing the issue.
Tested-by: NAngelo Cano <acano@fastmail.fm>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Some mt9v011 webcams report 0x8332 chip version, instead of 0x8243. From
the revision history at the mt9v011 datasheet, it seems that the chip
version has changed from the first release of the chip.

Thanks-to hermann pitton <hermann-pitton@arcor.de> for pointing this to
me, on his tests with a Silvercrest webcam.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Pinnacle Hybrid Pro 320e was missing a demod config for the xc3028, which
is required for digital tuning to work properly.  Add the missing profile.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In cases where the device has a generic Empia USB ID, the call in the
precard setup phase did not set the tuner GPIO.  As a result, the tuner may
not be taken out of reset before attempting initialization in the analog
driver.

This problem was not seen before with the EVGA inDtube, since that particular
board has the analog GPIO setup to include taking the tuner out of reset.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment for the Pinnacle 320e.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Set the GPIO properly for the analog side of the Pinnacle Hybrid Pro, or else
the emp202 doesn't get detected properly.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Setup the GPIOs properly and enable support for the DVB side of the Pinnacle
Hybrid Pro USB stick.

Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.

Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Wally <wally@voosen.eu> for bringing the issue and helping
with the tests.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Depending on the video input format, vinmode/vinctl needs adjustments.
For TV, this is not relevant, since the supported decoders output data
at the same format. However, webcam sensors may have different formats,
so, this needs to be adjusted based on the device.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In order to properly estimate fps, mt9v011 sensor driver needs to know
what is the used frequency on the sensor cristal. Adds the proper fields
and initialization code for specifying the cristal frequency.

Also, based on experimentation, it was noticed that the Silvercrest is
outputing data at 7 fps. This means that it should be using a 6.3 MHz
cristal. This information needs to be double checked later, by opening
the device. Anyway, by using this value for xtal, at least now we have
the correct fps report.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do
work with em28xx + webcam. The issue is that the scaling setup depends
on the number of visible rows/cols of the input image.

With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling
is different from a normal TV image (720x480 on NTSC). This were causing
a wrong scaling and a previous patch disabled scaling.

As each sensor have their different resolution setting, the xres/yres
should be adjusted accordingly with the input sensor.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With the previous approach, autodetection were working only for the two
generic entries (em275x and em2820 unknown ones). So, if someone would
try to force probing an specific device, the code would not properly run
the autodetection code.

With the new approach, the sensor autodetection will be run not only for
the two generic entries, but also do webcam specific ones.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Instead of using em28xx board decoder field for storing sensor information,
let's use instead a separate field for it.

Also, as sensors are currently autodetected, there's no need of having
it at the boards description. So, move it to the main em28xx struct.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Webcams in general don't have eeprom. So, the sensor hint code should be
called to properly detect what sensor is inside.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

By having the webcam devices marked as such, it will help the em28xx
driver to do the right thing on those devices.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Just renames the flag, to use a clearer name. Later patches will use
this flag to properly set some drivers behaviors for webcams.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Fix the code so that the zl10353 version of the Terratec Cinergy T XS USB
starts working again.  This includes fixing what must have been a typo in the
GPIO definition for the digital side of the board, and setting of the
disable_i2c_gate_ctrl property for the zl10353 config, so that the i2c bus
doesn't get wedged the first time something tries to close the gate.

Also, add a printk() making clear that the mt352 version still isn't
supported.  This issue is still being actively debugged, but in the meantime
at least the dmesg output will show a very clear error...

Thanks to Jelle de Jong for providing sample hardware to test with.

Thanks to Simon Kenyon for testing various patches and providing SSH access to
his environment so I could debug with access to a valid signal source.

Cc: Jelle de Jong <jelledejong@powercraft.nl>
Cc: Simon Kenyon <simon@koala.ie>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This webcam uses a em2710 chipset, that identifies itself as em2820,
plus a mt9v011 sensor, and a DY-301P lens.

It needs a few different initializations than a normal em28xx device.

Thanks to Hans de Goede <hdegoede@redhat.com> and Douglas Landgraf
<dougsland@redhat.com> for providing the acces for the webcam during
this weekend, I could make a patch for it while returning back from
FISL/Fudcom LATAM 2009.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add an IR profile for the EVGA inDtube remote control (which is an NEC type
remote)
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for the EVGA inDtube.  Both ATSC and analog side validated as
fully functional.

Thanks to Jake Crimmins from EVGA for providing the correct GPIO info.
Thanks to Alan Hagge for doing all the device testing.
Thanks to Greg Williamson for providing hardware for testing.

Cc: Jake Crimmins <jcrimmins@evga.com>
Cc: Alan Hagge <ahagge@gmail.com>
Cc: Greg Williamson <cheeseboy16@gmail.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In cases where the board had a default USB ID, we would not indentify the
board until after the call to em28xx_set_mode().  As a result, for those
boards the analog GPIOs were not being set before probing the i2c bus for
devices (the probe would occur with the GPIOs being all high).

Make a call to em28xx_set_mode() so that the GPIOs are set properly before
probing the i2c bus for devices.

This problem was detected with the EVGA inDtube, where the tvp5150 is not
powered on unless GPIO1 is pulled low.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Added an entry for Kworld 315 (for while, dvb only)
Signed-off-by: NFranklin Meng <fmeng2002@yahoo.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Added tda9887_conf set up into em28xx_card_setup()
Signed-off-by: NFranklin Meng <fmeng2002@yahoo.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add an em28xx module option that allows a user to override the USB speed check.
Intended for advanced users who understand the consequences of trying to use
the device with a 12Mbps bus.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Make the KWorld 2800d work properly.  In this case, that means making the
profile more generic so that it works for both the Pointnix Intra-Oral USB
camera and the KWorld device.

The device provides the audio through a pass-thru cable, so we don't need
an actual audio capture profile (neither the K-World device nor the Pointnix
have an onboard audio decoder).

Thanks to Paul Thomas for providing sample hardware.

Cc: Paul Thomas <pthomas8589@gmail.com>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The em28xx basically just doesn't work at 12 Mbps.  The isoc pipe needs
nearly 200 Mbps for analog support, so users would see garbage video, and on
the DVB/ATSC side scanning is likely to work but if the user tried to tune it
would certainly appear to have failed.

It's better to fail explicity up front and tell the user to plug into a USB 2.0
port, than to let the driver load and the user have weird problems with tuning
and garbage video.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

For specific boards, pass initialization data to ir-kbd-i2c instead
of modifying the settings after the device is initialized. This is
more efficient and easier to read.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>