This is part of the old V4L1->V4L2 bttv patch, ported to current tree
by Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: NNickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This is part of the old V4L1->V4L2 bttv patch, ported to current tree
by Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: NNickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This is part of the old V4L1->V4L2 bttv patch, ported to current tree
by Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: NNickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fix i2c reads and writes of 16bit register address / values
Signed-off-by: NSteven Toth <stoth@hauppauge.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Convert the usbvision->lock semaphore to the mutex API
Signed-off-by: NMatthias Kaehlcke <matthias.kaehlcke@gmail.com>
Reviewed-by: NThierry MERLE <thierry.merle@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

saa7134_buffer_requeue() and set_tvnorm() can become static.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This board has some special tea5767 configuration. Basically, radio 
XTAL uses a different frequency than the other supported radios. It 
uses a 13 MHz XTAL.

This patch adds the proper radio gpio and tea5767 configurations for 
the board.

Also, with PAL/BG, the board requires some special init for tda9887:
port1=0 port2=0 qss=1

Thanks to Serge Kolotylo and MIDImaster for their help on identifying 
the proper needs for this driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

tea5767 has several possible configurations. Before the patch, the
driver were assuming the more common configuration. However, some newer
cards, like MSI @nyware Master requires other configurations, like
de-activating a gpio port and changing chip Xtal.

This patch adds the capability of altering device configuration at
runtime. This may also be used later to activate some features like
auto-mute when signal is weak.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Currently, the only tuner-specific device that allows special
configurations is tda9887. However, tea5767 also may require some
special configurations (for example, to specify a different Xtal freq).

This patch replaces TDA9887_SET_CONFIG by a more generic internal ioctl
(TUNER_SET_CONFIG). The newer one allows specifying what tuner is
appliable to a configuration set, and allows an arbitrary configuration
struct.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Correct wrong sized spinlock flags, form int to unsigned long.
Signed-off-by: NDaniel Walker <dwalker@mvista.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Using an udelay of 5 seems to result in problems for several people.
For now abandon the udelay value of 5 and stick to 10, even though this
will mean a longer load time of the cx2584x firmware.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The eeprom decides which Hauppauge model it is, so the decision whether to
use an udelay of 5 or 10 needs to be taken after reading the eeprom, not
before.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fix bttv VIDIOCGMBUF locking like done in commit
820eacd8. 
Signed-off-by: NGregor Jasny <gjasny@web.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

usage_count got removed.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Hermann Pitton for noticing that this was missing.
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Cc: Hermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

After commit 19fb1457 the callers in
videobuf-core.c that already hold the lock must call
__videobuf_read_start() instead of videobuf_read_start().
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

videobuf_dvb needs videobuf_read_start. The EXPORT_SYMBOL_GPL() were removed by
a previous patch. However, videobuf_dvb needs this.

This patch re-adds videobuf_read_start, doing the proper lock.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:

<--  snip  -->

...
...

<--  snip  -->
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This patch fixes the following section mismatch with CONFIG_HOTPLUG=n:

<--  snip  -->

...
...

<--  snip  -->
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

There are several months my hvr1110 stop working.
This is very simple to fix, for my card revision at least, by setting a
missing field to the hauppauge_hvr_1110_config.
Signed-off-by: NBenoit Istin <beistin@gmail.com>
Signed-off-by: NMichael Krufky <mkrufky@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This is pretty serious bug.  map->count is never initialized after the
call to kmalloc making the count start at some random trash value.  The
end result is leaking videobufs.

Also, fix up the debug statements to print unsigned values.

Pushed to http://ifup.org/hg/v4l-dvb too
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The saa7134 video driver starts dropping frames when used together with the
saa7134-alsa driver. Frames are dropped because when an audio event is waiting
the driver simply ignores the interrupt and passes it on to the saa7134-alsa
interrupt handler. The alsa interrupt handler in turn acknowledges all types
of events thus clearing the pending video events as well. Fix by only masking
out the audio event in the video interrupt handler and by only acknowledging
the audio event in the alsa driver.
Signed-off-by: NHeikki Lindholm  <holindho@cs.helsinki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The vmux for composite over s-video input was wrong.
Signed-off-by: NHermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Complement va_start() with va_end() + minor style fixes in the same function.
Signed-off-by: NRichard Knutsson <ricknu-0@student.ltu.se>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The period handling in saa7134-alsa is broken in two ways. First, the
minimum number of periods of two does not work, because the dma is setup
two periods ahead in the irq handler. Fix the minimum to four periods.
Second, the code assumes that the number of periods is divisible by two,
which isn't always the case on ALSA. Fix by adding a constraint.
Signed-off-by: NHeikki Lindholm  <holindho@cs.helsinki.fi>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Drivers were using cookie cutter code for stopping the read/stream.  Use the
new videobuf_stop function which is lock safe.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

- Add comments to functions that require that caller hold q->lock
- Add __videobuf_mmap_free that doesn't hold q->lock for use within videobuf
- Add locking to videobuf_mmap_free
- Fix linux/drivers/media/common/saa7146_video.c which was holding lock around
  videobuf_read_stop
- Add locking to functions that operate on a queue
- Add videobuf_stop to take care of stopping in both the read and stream case

TODO: bttv still has an unsafe call to videobuf_queue_is_busy
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Thanks to Markus Reichberger to point this.
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The attached patch is required so that the autodetecion code also works after
a reboot.

Setting the I2C speed does not seem to be supported for em2800.
Signed-off-by: NSascha Sommer <saschasommer@freenet.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The pvrusb2 driver is tearing down its sysfs related pieces in the
incorrect order.  This leaves dangling pointers which causes the
kernel device core to oops.  The problem has been present virtually
forever but became malignant with the changeover to the way of
handling /sys/class.  Fix is just to make sure we don't tear down the
class structure until AFTER the driver instances are deregistered.
Signed-off-by: NMike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

vivi.c is a virtual driver that builds without PCI and should run on
non-pci hardware.
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

From: Ludovico Cavedon <cavedon@sssup.it>
Signed-off-by: NLudovico Cavedon <cavedon@sssup.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

This em28xx-video.c uses functions from this header, but doesn't include it.
It depends on some v4l headers included two levels down including poll.h,
which includes mm.h.

These v4l headers might change, so it's best to include the headers needed
directly.

It also causes problems for the out of core build system's backward
compatibility with older kernels, which is the real reason I bothered to
create a patch for something that would otherwise be so minor that it would
hardly be worth the trouble.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Trent Piepho wrote:
> I do not think the saa7134-alsa driver supports mmap.  The cx88-alsa driver
> also claimed to support mmap, but it never worked until I fixed it.  It's
> pretty clear that the code in saa7134-alsa was based on the same code as
> cx88-alsa, so it's likely it has the same bug.

You are right. The patch below (based on your cx88 patch, but I don't
really understand it) fixes mmap support in saa7134-alsa for me.
Recording via mmap (arecord -M -f S16_LE -c 2 -r 32000 -D hw:1) didn't
work at all before, works now, tested for at least 20 minutes (but,
unfortunately, with one overrun at least 0.719 ms long).
Signed-off-by: NAlexander E. Patrakov <patrakov@ums.usu.ru>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>