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>

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>

Add the image quality bridge controls contrast, brightness, saturation,
blue balance, red balance and sharpness.
These controls are enabled only if no subdevice provides them.
Tested with the following devices:
"Terratec Cinergy 200 USB"
"Hauppauge HVR-900"
"SilverCrest 1.3MPix webcam"
"Hauppauge WinTV USB2"
"Speedlink VAD Laplace webcam"
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>

Seems to work just the same as older revisions.
Signed-off-by: NRoland Scheidegger <rscheidegger_lists@hispeed.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Remy Blank reported that audio over USB can be made working for the television
input if .amux is changed from EM28XX_AMUX_LINE_IN to EM28XX_AMUX_VIDEO.
An examination of his devices shows, that it is indeed supplied with an EM202
AC97 audio IC. We also use this setting for the Cinergy 200.
Remy Blank also provided the original version of this patch (many thanks !).
Fixes bug 14126 (see bug report for further device details).
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NRemy Blank <remy.blank@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The main purpose of this patch is to move the call of em28xx_release_resources()
after the call of em28xx_close_extension().
This is necessary, because some resources might be needed/used by the extensions
fini() functions when they get closed.
Also mark the device as disconnected earlier in this function and unify the
em28xx_uninit_usb_xfer() calls for analog and digital mode.
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>

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>

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>

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>

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

The current enpoint logic ignores all bulk endpoints and uses
a fixed mapping between endpint addresses and the supported
data stream types (analog/audio/DVB):
  Ep 0x82, isoc	=> analog
  Ep 0x83, isoc	=> audio
  Ep 0x84, isoc	=> DVB
Now that the code can also do bulk transfers, the endpoint
logic has to be extended to also consider bulk endpoints.
The new logic preserves backwards compatibility and reflects
the endpoint configurations we have seen so far:
  Ep 0x82, isoc		=> analog
  Ep 0x82, bulk		=> analog
  Ep 0x83, isoc*	=> audio
  Ep 0x84, isoc		=> digital
  Ep 0x84, bulk		=> analog or digital**
 (*: audio should always be isoc)
 (**: analog, if ep 0x82 is isoc, otherwise digital)

[mchehab@redhat.com: Fix a CodingStyle issue: don't break strings
 into separate lines]
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

Rename the existing function for isoc transfers em28xx_init_isoc
to em28xx_init_usb_xfer and extend it.
URB allocation and setup is now done depending on the USB
transfer type, which is selected with a new function parameter.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This function will be used to uninitialize USB bulk transfers, too.
Also rename the local variable isoc_bufs to usb_bufs.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rename EM28XX_NUM_PACKETS to EM28XX_NUM_ISOC_PACKETS and
EM28XX_DVB_MAX_PACKETS to EM28XX_DVB_NUM_ISOC_PACKETS to
clarify that these values are used only for isoc usb transfers.
Also use the term num_packets instead of max_packets, as this
is how these values are used and called in struct urb.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

drivers/media/usb/em28xx/em28xx-cards.c:3309:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This intializes the card just like the windows driver does

- the "HTC USB XS HD" uses the same firmware as the "HTC Stick HD";
- both have different GPIO and reg init sequences;

Tested only with DVB-C.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This kind of memcpy() is error-prone and its
replacement with a struct assignment is prefered.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

em28xx-dvb, em28xx-alsa and em28xx-ir are typically initialized
asyncrhronously. The exception for it is when those modules
are loaded before em28xx (or before an em28xx card insertion) or
when they're built in.

Make the extentions to always load asynchronously. That allows
having all DVB firmwares loaded synchronously with udev-182.

Antti tested it with the following hardware:
	Hauppauge WinTV HVR 930C
	MaxMedia UB425-TC
	PCTV QuatroStick nano (520e)
Tested-by: NAntti Palosaari <crope@iki.fi>
Cc: stable@kernel.org # for Kernel 3.6 - please note that driver location has changed
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Rename all USB drivers with their own directory under
drivers/media/video into drivers/media/usb and update the
building system.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The logic that checks if a device has remote control is wrong.
Due to that, the em28xx RC module is not loaded by default.

Fix the logic, in order to make it work properly.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The windows driver used different values for the GPIOs and analog
decoder configuration. The values from the windows driver are now
used.
It also seems that the windows driver has LNA always disabled.
Thus we are doing the same (using the same flags as on windows).

I (only) tested with DVB-T and it worked quite well.

[mchehab@redhat.com: Fix merge conflicts and tested with DVB-C]
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The Cinergy HTC Stick HD uses the same remote control as the TerraTec
Cinergy XS products. Thus the same keymap could be re-used.
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Nobody ever waits on any of these wait_queue's,
so this patch removes them completely.
Tested by compilation only.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The list_head struct usage was fully removed by commit
d7aa8020.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This cleans namespace a bit by making em28xx_card_setup()
em28xx_pre_card_setup() static functions.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
[mchehab@redhat.com: Changed the default to follow the em28xx selection]
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This function is only used in em28xx-input.c so it
makes no sense to have it anywhere but in em28xx-input.c.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Moving this helps isolating em28xx_input and will help
converting it into a separate module.
Signed-off-by: NEzequiel Garcia <elezegarcia@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It is mostly copy/paste of the 520e code with setting GPIO7 removed
(no LED light).

I've worked on just released vanilla linux-3.3.0 kernel, so there may
be 1/2 lines offset to the internal working source, but most of the
code should apply cleanly.

I was able to get the DVB-C working (tuned and watched TV). Haven't
tested DVB-T (no signal atm).

Special thanks to everybody who worked on the code and to Antti
Palosaari and Devin Heitmueller who provided essential support on irc.

Hardware is based of:
Empia EM2884
Micronas DRX 3926K
NXP TDA18271HDC2
AVF4910 (not used atm)
Signed-off-by: NIvan Kalvachev <ikalvachev@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hardware is based of:
Empia EM2884
Micronas DRX 3926K
NXP TDA18271HDC2

... + analog parts.
Analog is not supported currently. Only DVB-T and DVB-C.

There seems to be still	problems for locking DVB-C channels which have
strong signal. Attenuator helps. I think it is demodulator IF/RF AGC
issue. Lets fix it later. Patches are welcome.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Hardware is based of:
Empia EM2874B
Micronas DRX 3913KA2
NXP TDA18271HDC2

Only DVB-C supported currently since missing firmware.
According to my tests, DRX 3913KA2 demodulator requires firmware
in order to support DVB-T mode.
Signed-off-by: NAntti Palosaari <crope@iki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>