The audio configuration in chip config register 0x00 and eeprom are always
consistent. But currently the audio configuration #defines for the chip config
register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the eeprom
info output says 0x20 means 1 sample rate and 0x30 3 sample rates.

I've checked the datasheet excerpts I have and it seems that the meaning of
these bits is different for em2820/40 (1 and 3 sample rates) and em2860+
(3 and 5 smaple rates).
I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom
audio config 0x20 matches the sample rates reproted by the USB device
descriptor (32k only).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Use the same module version on all em28xx sub-modules, and use
the same naming convention to describe the driver.
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Now that all analog-specific code are at em28xx-video, convert
it into an em28xx extension and load it as a separate module.
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Tested-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

In order to make easier for the next patches, do some
cosmetic changes.

No functional changes.
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Now that we want to split the video handling to a separate
module, move all video-specific functions to em28xx-video.

No functional changes.
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

For GPI-connected buttons without (hardware) debouncing, the polling interval
needs to be reduced to detect button presses properly.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Device has following chips: Empia EM28178, Montage M88DS3103,
Montage M88TS2022, Allegro A8293.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The SpeedLink Vicious And Devine Laplace webcam is using an EM2765 bridge and
an OV2640 sensor. It has a built-in microphone (USB standard device class)
and provides 3 buttons (snapshot, illumination, mute) and 2 LEDs (capturing/mute
and illumination/flash). It is also equipped with an eeprom.
The device is available in two colors: white (1ae7:9003) and black (1ae7:9004).
For further details see http://linuxtv.org/wiki/index.php/VAD_Laplace.
Please note the following limitations that need to be addressed later:
- resolution limited to 640x480 (sensor supports 1600x1200)
- picture quality needs to be improved
- AV-mute button doesn't work yet
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The SpeedLink VAD Laplace webcam is equipped with an illumination button and
an illumination LED. When the button is pressed, the driver must toggle the
LED state via the corresponding GPO port.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Introduce a LED role and store all LEDs in an array.
Also provide a helper function to retrieve a specific LED.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

So far, the driver only supports a snapshot button which is assigned to
register 0x0c bit 5. This special port has a built-in debouncing mechanism.
For buttons connected to ordinary GPI ports, this patch implements a software
debouncing mechanism.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The current code supports only a single snapshot button assigned to
register 0x0c bit 5. But devices may be equipped with multiple buttons
with different functionalities and they can also be assigned to the
various GPI-ports.
Extend the em28xx-input code to handle multiple buttons assigned to different
GPI-ports / register addresses and bits.
Also make easier to extend the code with further button types.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Some devices are equipped with a capturing status LED that needs to be
switched on/off explicitly via a GPO port.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

This patch adds support for the UB435-Q V2. You might need to
use the device once with the Windows driver provided by KWorld
in order to permanently reprogram the device descriptors. Thanks
to Jarod Wilson for the initial attempt at adding support for this
device.

[m.chehab@samsung.com: Fixed Whitespace mangling, Coding Style and
 improved the error handling at DVB attach]
Signed-off-by: NJean-Francois Thibert <jfthibert@google.com>
Reviewed-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

Camera sensors usually require a master clock for data sampling. This patch
registers such a clock source for em28xx cameras. This fixes the currently
broken em28xx ov2640 camera support and can also be used by other camera
sensors.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>

The GPIO register caching is the result of wrong assumptions and incomplete
knowledge about the GPIO registers and their functionality.
Today, we know that it is not needed.
It is also limited to a single register and therefore incomplete (newer chips
are using multiple registers).
Instead of extending the caching, get rid of it, because it has no real
benefits and just bloats/complicates the code.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hardware is the same as MaxMedia UB425-TC but ships with a different
remote.
Signed-off-by: NJakob Haufe <sur5r@sur5r.net>
Reviewed-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This sensor is used by the "SpeedLink Vicious And Devine Laplace webcam" and
others. It supports resolutions up to 1600x1200 (at 7-8 fps), but for
resolutions higher than 640x480, further driver changes will be necessary,
such as sensor output resolution switching (including further configuration
changes), bridge xclk adjustment and disabling of 16 bit (12 bit) output formats
at high resolutions. Image quality should also needs to be improved.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx-cards.c is very large and the sensor/camera related code is growing,
so move this code to a separate source code file em28xx-camera.c.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This chip can be found in the SpeedLink VAD Laplace webcam (1ae7:9003 and 1ae7:9004).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The webcam "SpeedLink VAD Laplace" (em2765 + ov2640) uses a special algorithm
for i2c communication with the sensor, which is connected to a second i2c bus.
We don't know yet how to find out which devices support/use it.
It's very likely used by all em25xx and em276x+ bridges.
Tests with other em28xx chips (em2820, em2882/em2883) show, that this
algorithm always succeeds there although no slave device is connected.
The algorithm likely also works for real i2c client devices (OV2640 uses SCCB),
because the Windows driver seems to use it for probing Samsung and Kodak
sensors.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is an hybrid board. However, for analog, it requires
a new driver for saa7136. So, for now, let's just add
support for Digital TV.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Register both buses 0 and 1 via I2C API. For now, bus 0 is used
only by eeprom on all known devices. Later patches will be needed
if this changes in the future.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Prepare to register a separate bus for the second bus.
For now, just add a new field. A latter patch will add the
bits to make it work.
This patch was generated by this script:
perl -e 'while (<>) { if (s/EM2874_I2C_SECONDARY_BUS_SELECT.*\n//) {
	printf "\t\t.def_i2c_bus  = 1,\n"; $found = 1; print $_ } else { if ($found) { s/^\s+// }; $found = 0; print $_; } }' \
drivers/media/usb/em28xx/em28xx-cards.c >a && mv a drivers/media/usb/em28xx/em28xx-cards.c
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Newer em28xx devices have 2 buses. Change the logic to allow
using both buses.
This patch was generated by this small script:
for i in drivers/media/usb/em28xx/*.c; do
	sed 's,->i2c_adap,->i2c_adap[dev->def_i2c_bus],g;s,->i2c_client,->i2c_client[dev->def_i2c_bus],'
done
Of course, em28xx.h needed manual edit.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The new eeproms with 16 address width still have the the device config dataset
(the content of the old 8 bit eeproms) embedded.
Hauppauge also continues to include the tveeprom data structure inside this
dataset in their devices.
The start address of the dataset depends on the start address of the microcode
and a variable additional offset.
It should be mentioned that Camera devices seem to use a different dataset type,
which is not yet supported.
Tested with devices "Hauppauge HVR-930C". I've also checked the USB-log from the
"MSI Digivox ATSC" and it works the same way.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We currently reserve an array of 256 bytes for the eeprom content in the device
struct. For eeproms with 16 bit address width it might even be necessary to
increase the buffer size further.
Having such a big chunk of memory reserved even if the device has no eeprom and
keeping it after it has already been processed seems to be a waste of memory.
Change the code to allocate + free the eeprom memory dynamically.
This also makes it possible to handle different dataset sizes depending on what
is stored/found in the eeprom.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Newer devices (em2874, em2884, em28174, em25xx, em27[6,7,8]x) use eeproms with
16 bit instead of 8 bit address width.
The used eeprom type depends on the chip type, which makes sure eeproms can't
be damaged.
This patch adds basic support for 16 bit eeproms only, which includes
- reading the content
- calculating the eeprom hash
- displaying the content
The eeprom content uses a different format, for which support will be added with
subsequent patches.
Tested with the "Hauppauge HVR-930C" and the "Speedlink VAD Laplace webcam"
(with additional experimental patches).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The data is stored as little endian in the eeprom.
Hence the correct data types should be used and the data should be converted
to the machine endianess before using it.
The eeprom id (key) also isn't a 32 bit value but 4 separate bytes instead.

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

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

We already have the key polling functions and the polling infrastructure in
em28xx-input, so we can easily get rid of the dependency on module ir-kbd-i2c.
For maximum safety, do not touch the key reporting mechanism for those devices.
Code size could be improved further but would have minor peformance impacts.
Tested with device "Terratec Cinergy 200 USB" (EM2800_BOARD_TERRATEC_CINERGY_200)

[mchehab@redhat.com: Fix two checkpatch.pl warnings:
 ERROR: "foo * bar" should be "foo *bar" (line 465)
 WARNING: kfree(NULL) is safe this check is probably not required (line 725)]
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Function em2800_i2c_recv_bytes() has 2 severe bugs:
1) It does not wait for the i2c read to complete before reading the received message content from the bridge registers.
2) Reading more than 1 byte doesn't work
The former can result in data corruption, the latter always does.
The rewritten code also superseds the content of function
em2800_i2c_check_for_device().
Tested with device "Terratec Cinergy 200 USB".

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

DEV_INITIALIZED of enum em28xx_dev_state state is used nowhere and there is no
need for DEV_MISCONFIGURED, so remove this enum and use a boolean field
'disconnected' in the device struct instead.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch converts the em28xx driver over to videobuf2.  It is
likely that em28xx_fh can go away entirely, but that will come in
a separate patch.

[mchehab@redhat.com: fix a non-trivial merge conflict with some VBI
 patches; CodingStyle fixes]
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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