V4L1 ioctls were replaced to V4L2 were applicable. The older ones
already implemented were removed.
Signed-off-by: Mauro 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: Nickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: Mauro 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: Nickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: Mauro 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: Nickolay V. Shmyrev <nshmyrev@yandex.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
saa7134_buffer_requeue() and set_tvnorm() can become static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro 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: Mauro 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: Mauro 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: Mauro Carvalho Chehab <mchehab@infradead.org>
Correct wrong sized spinlock flags, form int to unsigned long.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Linus 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: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro 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: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Thanks to Hermann Pitton for noticing that this was missing.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Cc: Hermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
After commit 19fb145799 the callers in
videobuf-core.c that already hold the lock must call
__videobuf_read_start() instead of videobuf_read_start().
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Mauro 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: Mauro 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: Benoit Istin <beistin@gmail.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro 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: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro 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: Heikki Lindholm <holindho@cs.helsinki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The vmux for composite over s-video input was wrong.
Signed-off-by: Hermann Pitton <hermann-pitton@arcor.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Complement va_start() with va_end() + minor style fixes in the same function.
Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
Signed-off-by: Mauro 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: Heikki Lindholm <holindho@cs.helsinki.fi>
Signed-off-by: Mauro 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: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro 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: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro 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: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Mauro 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: Mike Isely <isely@pobox.com>
Signed-off-by: Mauro 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: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro 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: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro 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: Alexander E. Patrakov <patrakov@ums.usu.ru>
Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
