This workaround fix a bug that happens on some SMP machines. On those machines,
videobuf_iolock is called too soon, before file .mmap handler. This patch calls
the scheduler before iolocking, allowing it to properly call the pending mmap.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Before the videobuf redesign, a procedure for re-using videobuf without PCI
scatter/gather where provided by changing the pci-dependent operations by
other operations.
With the newer approach, those methods are obsolete and can safelly be removed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
cx23885 driver were converted to use the newer videobuf support. Unfortunately,
the constructor weren't changed. This causes an oops, since the abstract methods
(implemented as callbacks) aren't defined.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Reviewed-by: Michael Krufky <mkrufky@linuxtv.org>
No need to cast the void pointer returned by kmalloc() in
drivers/media/video/zoran_driver.c::v4l_fbuffer_alloc().
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
cx23885 was still uses the old video-buf includes and code, which would only
`work' if one happened to be compiling against a kernel that had the old
headers. Even then, it wouldn't actually work, it would just compile without
errors.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
CONFIG_VIDEO_BUF_DVB became CONFIG_VIDEOBUF_DVB.
But in these cases, it makes more sense to use CONFIG_VIDEO_SAA7134_DVB
or CONFIG_VIDEO_CX88_DVB_MODULE depending on the driver.
The reference in cx23885.h should just be removed, as the code there needs to
be included if DVB is on or off. I do not think you can even compile the
cx23885 driver without DVB. It's clearly just leftover from when the file was
obvious copied from the cx88 driver (which is not mentioned in the copyright
BTW).
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Here's an attempted update to the full kthread API + wake_up_process:
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
CC: Andrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
If videobuf_read_stream reads two or more buffers it was overwriting the first one
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981
Reviewed-by: Ricardo Cerqueira <v4l@cerqueira.org>
The reading/streaming fields are used for mutual exclusion of the queue and
should be protected by the queue lock.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981
Reviewed-by: Ricardo Cerqueira <v4l@cerqueira.org>
The "resource" locking in vivi isn't needed since
streamon/streamoff/read_stream do mutual exclusion using
q->reading/q->streaming.
Plus it is sort of broken:
a) res_locked() use in vivi_read() is racey.
b) res_free() calls mutex_lock twice causing streamoff to break
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Since vivi is using videobuf_read_stream() it can use videobuf_poll_stream()
now.
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
If the client provides V4L2_FIELD_ANY vivi should return a valid field :)
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
By "capturing interlaced video" I mean that card ensures that top field
is really top and vice versa (I think it takes the filed ID from signal)
Properly turn on/off that support depending on signal state
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This adds support for suspend/resume for core of saa7134
Should fix bug#7220
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
When user sets dev->ctl_invert, driver writes negative values to
SAA7134_DEC_LUMA_CONTRAST and SAA7134_DEC_CHROMA_SATURATION,
but general code that initializes decorder ignores that
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
set_tvnorm can sleep in saa7134_i2c_xfer
(it will be called through tuner code)
but code calls it under spinlock. Fix that
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
videobuf_qbuf takes q->lock, and then calls
q->ops->buf_prepare which by design in all drivers calls
videobuf_iolock which calls videobuf_dma_init_user and this
takes current->mm->mmap_sem
on the other hand if user calls mumap from other thread, sys_munmap
takes current->mm->mmap_sem and videobuf_vm_close takes q->lock
Since this can occur only for V4L2_MEMORY_MMAP buffers, take
current->mm->mmap_sem in qbuf, before q->lock, and don't take
current->mm->mmap_sem videobuf_dma_init_user for those buffers
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981
Reviewed-by: Ricardo Cerqueira <v4l@cerqueira.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
While this is not the standard color bar behaviour, having some movement
there allows to check if buffers are being properly handled.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Due to the replace of videobuf_read_one to videobuf_read_stream, poll()
method implementation is wrong. This fixes poll() implementation, making
read of /dev/video? to work again.
With this method, an USB driver can use video-buf, without needing to
request memory from the DMA-safe area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
This patch removes the usage of videobuf-dma-sg from vivi driver, using
instead videobuf-vmalloc. This way, vivi will be useful for testing the
newer method. Reverting this patch won't hurt vivi, since both methods
work fine.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Adds a newer videobuf-vmalloc module. This module uses the same
videobuf controls, but implements memory allocation based on vmalloc
methods.
With this method, an USB driver can use video-buf, without needing to
request memory from the DMA-safe area.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
PCI-dependent videobuf_foo methods were renamed as videobuf_pci_foo.
Also, videobuf_dmabuf is now part of videobuf-dma-sg private struct.
So, to access it, a subroutine call is needed.
This patch renames all occurences of those function calls to be
consistent with the video-buf split.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981
Reviewed-by: Ricardo Cerqueira <v4l@cerqueira.org>
video-buf currently does two different tasks:
- Manages video buffers with a common code that allows
implementing all the V4L2 different modes of buffering;
- Controls memory allocations
While the first task is generic, the second were written to support PCI DMA
Scatter/Gather needs. The original approach can't even work for those
video capture hardware that don't support scatter/gather.
I did one approach to make it more generic. While the approach worked
fine for vivi driver, it were not generic enough to handle USB needs.
This patch creates two different modules, one containing the generic
video buffer handling (videobuf-core) and another with PCI DMA S/G.
After this patch, it would be simpler to write an USB video-buf and a
non-SG DMA module.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
http://thread.gmane.org/gmane.comp.video.video4linux/34978/focus=34981
Reviewed-by: Ricardo Cerqueira <v4l@cerqueira.org>
Adds an entry for the Typhoon Tv-Tuner PCI to bttv-cards.c
Signed-off-by: Sascha Sommer <saschasommer@freenet.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
IR workqueue should be disabled during suspend. This avoids some troubles, like
the one reported on bug #8689:
"The Hauppauge HVR 1100 ir-remote control does not work after resume from
suspend to ram or disk."
This patch disables IR before suspending, re-enabling it after resume.
Thanks to Peter Poklop <Peter.Poklop@gmx.at> for reporting it and helping with
the fix.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Reviewed-by: Peter Poklop <Peter.Poklop@gmx.at>
Redoes the way the control word is stored and set.
The existing code was a lot more complicated than it needed to be.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Reviewed-by: Pekka Seppänen <pexu@kapsi.fi>
Frequency calculation to use better math. It's still the same
IF offset and step size (which are not the same as the datasheet says) as
the code was before. It's just more efficient and accurate.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Reviewed-by: Pekka Seppänen <pexu@kapsi.fi>
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Code cleanup for GemTek Radio card driver. Removed unnecessary / invalid
I/O commands and rewrote code for tuning on-board BU2614FS chip. Adds
several new module params for power users. Includes automatic device
probing.
Signed-off-by: Pekka Seppanen <pexu@kapsi.fi>
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Reviewed-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Details now match with radio-gemtek.c, eg. no more different ports.
Included a short note about cards that should be compatible with
radio-gemtek module.
Signed-off-by: Pekka Seppanen <pexu@kapsi.fi>
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Reviewed-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Fixes use of parport_write_control() to match the newer interface that
requires explicit parport_data_reverse() and parport_data_forward() calls.
This eliminates the following error message and restores the original
intended behavior:
parport0 (bw-qcam): use data_reverse for this!
Also increases threshold in qc_detect() from 300 to 400, as my camera often
results in a count of approx 330. Added a kernel error message to indicate
detection failure.
Thanks Ray and Randy for your comments, and for pointing out that I
needed to reset the port to forward mode!
Signed-off-by: Brett T. Warden <brett.warden@gmail.com>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The pwc driver is defficient in locking, which can trigger an oops
when disconnecting.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: Luc Saillard <luc@saillard.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
By default, we allocate DMA buffers when actually reading from the video
capture device. On a system with 128MB or 256MB of ram, it's very easy
for that memory to quickly become fragmented. We've had users report
having 30+MB of memory free, but the cafe_ccic driver is still unable to
allocate DMA buffers.
Our workaround has been to make use of the 'alloc_bufs_at_load' parameter
to allocate DMA buffers during device probing. This patch makes DMA
buffer allocation happen during device probe by default, and changes
the parameter to 'alloc_bufs_at_read'. The camera hardware is there,
if the cafe_ccic driver is enabled/loaded it should do its best to ensure
that the camera is actually usable; delaying DMA buffer allocation
saves an insignicant amount of memory, and causes the driver to be much
less useful.
Signed-off-by: Andres Salomon <dilinger@debian.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The name of the pll will be shown if forced via insmod option,
or if debug is enabled.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Add a module option to force the dvb-pll module to use an alternate dvb-pll
description without having to recompile the kernel.
Having a module option like this is useful in some cases, where the vendor
may release an alternate revision of the hardware using a different tuner,
but without changing the pci subsystem / usb device ids.
This option is intended for debugging purposes _only_.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Increased DVB_PLL_MAX from 16 to a figure that would never be reached in a
practical sense.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
