Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add a routine for dumping the EEPROM of the MPC718.  It is generic enough
to use for other cards in the future that may have an EEPROM.
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch fixes some checkpatch warnings in mt312-driver.
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

input, inp and i are unsigned. When negative they are wrapped and caught by the
other test.

Cc: Andy Walls <awalls@radix.net>
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Cc: Patrick Boettcher <patrick.boettcher@desy.de>
Cc: Steven Toth <stoth@linuxtv.org>
Cc: Igor M. Liplianin <liplianin@netup.ru>
Cc: Srinivasa Deevi <srinivasa.deevi@conexant.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Acked-by: NAndy Walls <awalls@radix.net>
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>

Some Aveo Technology USB 2.0 Camera (1871:0306) revisions seem to require the
PROBE_MINMAX quirk. As the camera supports uncompressed YUYV data only, it's
safe to set the quirk even if not strictly required for all models. Update the
device entry in the device IDs list.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

To make UVC constants accessible by a future UVC gadget driver, move them from
drivers/media/video/uvc/uvcvideo.h to include/linux/usb/video.h.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Those constants are not used anymore, remove them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

In preparation to moving UVC constants to a public location, prefix all
constants with UVC_ to avoid namespace clashes.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

uvcvideo.h redefines class-specific descriptor types already present in
usb/ch9.h. Remove the duplicated definitions and use the ones from usb/ch9.h.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Thanks to Hans Verkuil <hverkuil@xs4all.nl> for pointing this issue on
my last patch.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

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

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

Signed-off-by: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

- Remove user count log messages
- Comments adopted to general style
Signed-off-by: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Add support for interrupt mode for RDS endpoint, instead of polling.
Improves RDS reception significantly
Signed-off-by: NEdouard Lafargue <edouard@lafargue.name>
Acked-by: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Reported-by: NToralf Forster <toralf.foerster@gmx.de>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
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>

The order of indexes is reversed
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAntoine Jacquet <royale@zerezo.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Update KConfig file to enbale selection of SDIO and USB
interfaces, and add dependancy on relevant modules.

[mchehab@redhat.com: fix merge conflicts, remove default: m, add missing endmenu]
Signed-off-by: NUdi Atar <udia@siano-ms.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fixed SDIO compilation bugs
Also fixed a memory overrun issue in buffer management.
Signed-off-by: NUdi Atar <udia@siano-ms.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>

Previous changesets broke Hauppauge devices and their GPIO configurations.

This changeset restores the LED & LNA functionality.
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This patch changes most frontend drivers to allocate their state structure via
kzalloc and not kmalloc. This is done to properly initialize the
embedded "struct dvb_frontend frontend" field, that they all have.

The visible effect of this struct being uninitalized is, that the member "id"
that is used to set the name of kernel thread is totally random.

Some board drivers (for example cx88-dvb) set this "id" via
videobuf_dvb_alloc_frontend but most do not.

So I at least get random id values for saa7134, flexcop and ttpci based cards.
It looks like this in dmesg:
DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S)

The related kernel thread then also gets a strange name
like "kdvb-ad-1-fe--1".

Cc: Michael Krufky <mkrufky@linuxtv.org>
Cc: Steven Toth <stoth@linuxtv.org>
Cc: Timothy Lee <timothy.lee@siriushk.com>
Cc: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: NMatthias Schwarzott <zzam@gentoo.org>
Acked-by: NAndreas Oberritter <obi@linuxtv.org>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

parport[n] is checked before n < MAX_CAMS
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

siano uses input_*() functions so it should depend on INPUT
to prevent build errors:

ERROR: "input_event" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_register_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_free_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_unregister_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_allocate_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!

Cc: Michael Krufky <mkrufky@linuxtv.org>
Cc: Uri Shkolnik <uris@siano-ms.com>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

It tested the value of stk_sizes[i].m before checking whether i was in range.

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Restore support for digital tuning caused by regression during introduction
of disable_i2c_gate parameter to zl10353 driver.

Thanks to user "Xwang" for reporting the problem and testing the fix

Cc: Xwang <xwang1976@email.it>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The v4l core supplies default handlers for G_STD and G_PARM. However, both
default handlers are buggy.

This patch fixes the following:

1) If no g_std is supplied and current_norm == 0, then this driver does not
   support TV video standards (e.g. a radio or webcam driver). Return
   -EINVAL. This ensures that there is no bogus VIDIOC_G_STD support for
   such drivers.

2) The default VIDIOC_G_PARM handler used current_norm instead of first
   checking if the driver supported g_std and calling that to get the norm.
   It also didn't check if current_norm was 0, since in that case the driver
   does not support TV standards (or no standard was set at all) and the
   default handler should return -EINVAL.

Note that I am very unhappy with these default handlers: I think they
basically behave like some very strange and unexpected side-effect.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Drivers should either set current_norm or supply a g_std callback.

The hdpvr driver does neither. Since it initializes to a 60 Hz format
I've initialized the current_norm to NTSC | PAL_M | PAL_60 which is the
60 Hz subset of tvnorms.

Cc: Janne Grunau <j@jannau.net>
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The .buf_queue() V4L2 driver method is called under
spinlock_irqsave(q->irqlock,...), don't take the lock again inside the
function.
Reported-by: NAntonio Ospite <ospite@studenti.unina.it>
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Fix build errors in zr364xx by adding selects:

zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon'
zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf'
zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf'
zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf'
zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs'
zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy'
zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free'
zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock'
zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper'
zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream'
zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one'
zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free'
zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init'
zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff'
zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc'
zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff'
drivers/built-in.o: In function `free_buffer':
zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free'
drivers/built-in.o: In function `zr364xx_open':
zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init'
drivers/built-in.o: In function `read_pipe_completion':
zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.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>