Currently, the logic to load ir i2c ancillary module is broken. It is
associated to Hauppauge devices with IR flag on their eeprom, no matter
if the device uses i2c or em28xx direct IR support. That's wrong.

Instead, add a flag to the boards that use i2c IR chips and load the
module only for those devices and if ir is not disabled.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

ir-kbd-i2c's ir_probe() function can be called much later (i.e. at
ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data
allocated off of the stack in cx18_i2c_new_ir() at registration time.
Make sure we pass a pointer to a persistent IR_i2c_init_data object at
i2c registration time.

Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to
rise this question.

Before this patch, if ir-kbd-i2c were probed after em28xx, trash data
were used. After the patch, no matter what order, it is properly
reported as tested by me:

input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10
ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0 [em28xx #0]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, V4L uses a scancode table whose index is the scancode and
the value is the keycode. While this works, it has some drawbacks:

1) It requires that the scancode to be at the range 00-7f;

2) keycodes should be masked on 7 bits in order for it to work;

3) due to the 7 bits approach, sometimes it is not possible to replace
the default keyboard to another one with a different encoding rule;

4) it is different than what is done with dvb-usb approach;

5) it requires a typedef for it to work. This is not a recommended
Linux CodingStyle.

This patch is part of a larger series of IR changes. It basically
replaces the IR_KEYTAB_TYPE tables by a structured table:
struct ir_scancode {
       u16     scancode;
       u32     keycode;
};

This is very close to what dvb does. So, a further integration with DVB
code will be easy.

While we've changed the tables, for now, the IR keycode handling is still
based on the old approach.

The only notable effect is the redution of about 35% of the ir-common
module size:

   text    data     bss     dec     hex filename
   6721   29208       4   35933    8c5d old/ir-common.ko
   5756   18040       4   23800    5cf8 new/ir-common.ko

In thesis, we could be using above u8 for scancode, reducing even more the size
of the module, but defining it as u16 is more convenient, since, on dvb, each
scancode has up to 16 bits, and we currently have a few troubles with rc5, as their
scancodes are defined with more than 8 bits.

This patch itself shouldn't be doing any functional changes.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

[mchehab@redhat.com: Fix a few wrong IR keymaps]
Signed-off-by: NShine Liu <shinel@foxmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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>