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>

[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>

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>

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>

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>

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

em28xx doesn't have temporal scaling. However, on webcams, sensors are
capable of changing the output rate. So, VIDIOC_[G|S]_PARM ioctls should
be passed to the sensor for it to properly set frame rate.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Implement g_parm/s_parm ioctls. Those are used to check the current
frame rate (in fps) and to set it to a value. In practice, there are
only 15 possible different speeds, due to chip limits.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

A user discovered that the Geniatech x8000 encountered a regression when
the xc3028 power management was introduced.  The xc3028 never recovers after
setting the powerdown register, which is probably because the xc3028 reset
GPIO is not properly configured.  Since I do not have access to the hardware
and thus cannot determine the correct GPIO configuration, just disable xc3028
power management on this board, which fixes the regression.

Thanks to user "ritec" for reporting the issue and testing the fix.

Cc: rictec <rictec@netcabo.pt>
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The introduction of the zl10353 i2c gate control broke support for the
Geniatech board (which is not behind an i2 gate).  Add the needed parameter.
Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The iSight sends non-UVC status events through the interrupt endpoint. Those
invalid events are reported to the kernel log, resulting in a log flood.

Only log the events when the UVC_TRACE_STATUS flag is set.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Commit 50144aee broke the Samsung NC10
netbook webcam. Instead of applying the FIX_BANDWIDTH quirk to all ViMicro
devices, list the devices explicitly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Currently, the VIDIOC_S_STD ioctl just returns -EINVAL regardless of
the norm passed.  This patch sets cx23885_mpeg_template.tvnorms and
cx23885_mpeg_template.current_norm so that the VIDIOC_S_STD will work.

Thanks to Joseph Yasi for pointing this out, even though this particular
fix was already pushed into a development repository, merge priority of
this changeset has been escalated as a result of Joseph posting this
identical patch.
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NJoseph A. Yasi <joe.yasi@gmail.com>
Reviewed-by: NSteven Toth <stoth@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Current tip is broken and does not switch back to DVB-T correctly
Signed-off-by: NSohail Syyed <linuxtv@hubstar.net>
Signed-off-by: NSteven Toth <stoth@kernellabs.com>
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>

This mistakenly tested against sizeof(freqs) instead of the array size. Due to
the mask the only illegal value possible was 3.
Reported-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This mistakenly tests against sizeof(freqs) instead of the array size. Due to
the mask the only illegal value possible was 3.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NAndy Walls <awalls@radix.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

mclk_get_divisor uses pcdev->soc_host.dev, make sure it is initialized.
Signed-off-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>

When enabling debug with v4l_debug set to 2 or greater, the driver
OOPS's on startup.  Checks dev pointer before dereferencing, in
order to prevent this OOPS.
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

IOCTLS will never get handled if we dont connect
video_ioctl2 to mpeg_fops.ioctl
Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Both tvaudio and the tuner share i2c address 0x42. The tvaudio module can
check whether it really is a tda9840, but the tuner can't. So the tvaudio
module must be loaded before the tuner module. This was also the case for
2.6.29, but the order was swapped in 2.6.30.

Thanks to Krzysztof Grygiencz for reporting and testing this.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

This is not just pure cosmetic, since the order affects the out-of-tree
module build at the -hg development tree.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: NBrian Johnson <brijohn@gmail.com>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>

The bug was introduced when adding the light frequency control
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>