videobuf_waiton() must unlock and relock ext_lock if it has to wait.
For that to happen it needs the videobuf_queue pointer.
Don't attempt to unlock/relock q->ext_lock unless it was locked in the
first place.
vb->state has to be protected by a spinlock to be safe.
This patch is based on code from Mauro Carvalho Chehab <mchehab@redhat.com>.
[mchehab@redhat.com: add extra argument to a few missing places]
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add an ext_lock argument to the videobuf init functions. This allows
drivers to pass the vdev->lock pointer (or any other externally held lock)
to videobuf. For now all drivers just pass NULL.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently videobuf uses the vb_lock mutex to lock its data structures.
But this locking will (optionally) move into the v4l2 core, which means
that in that case vb_lock shouldn't be used since the external lock is already
held.
Prepare for this by adding a pointer to such an external mutex and
don't lock if that pointer is set.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers can optionally set a pointer to a mutex in struct video_device.
The core will use that to lock before calling open, read, write, unlocked_ioctl,
poll, mmap or release.
Updated the documentation as well and ensure that v4l2-event knows about the
lock: it will unlock it before doing a blocking wait on an event and relock it
afterwards.
Ensure that the 'video_is_registered' check is done when the lock is held:
a typical disconnect will take the lock as well before unregistering the
device nodes, so to prevent race conditions the video_is_registered check
should also be done with the lock held.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Until now all fops except release and (unlocked_)ioctl returned an error
after the device node was unregistered. Extend this as well to the ioctl
fops. There is nothing useful that an application can do here and it
complicates the driver code unnecessarily.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The driver author seems to not worked on this driver since its conversion
from 2.2 to 2.4. Nobody is known to have a stradis hardware for testing. As
it still uses V4L1 API, BKL and probably some other old stuff, someone would
need to work on it to preserve the driver. Instead of investing time and
efforts to keep porting it to work with new API's, it seems better to just
drop the driver.
So, let's move it to drivers/staging and label it to die at 2.6.38, if nobody
cares enough to port parallel port support to gspca or to create a new driver
that uses the same gspca-cpia sub-driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cpia driver were re-written inside gspca driver, for USB devices. The only
functionality that were not migrated is the support for parallel port,
as:
1) the developer didn't find any hardware;
2) it doesn't seem important to keep support for a parallel port webcam,
as this is an obsolete technology;
3) the changes at gspca for it to work with parallel port would be very large;
4) this driver still uses BKL.
So, let's move it to drivers/staging and label it to die at 2.6.38, if nobody
cares enough to port parallel port support to gspca or to create a new driver
that uses the same gspca-cpia sub-driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are a few ancillary static routines used by ioctl functions
that takes bttv lock internally. As we'll be adding the same lock
for all ioctl's that need, we need to properly document them, to
avoid doing double locks
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
mpc512x kernel configurations without SPI support do not build:
drivers/media/video/fsl-viu.c: In function 'viu_open':
drivers/media/video/fsl-viu.c:1248: error: implicit declaration of function 'kzalloc'
drivers/media/video/fsl-viu.c:1248: warning: assignment makes pointer from integer without a cast
drivers/media/video/fsl-viu.c: In function 'viu_release':
drivers/media/video/fsl-viu.c:1335: error: implicit declaration of function 'kfree'
If CONFIG_SPI is enabled, the slab.h will be included in
linux/spi/spi.h which is included by media/v4l2-common.h
and the fsl_viu.c driver builds.
Let's incluce linux/slab.h directly to fix the build breakage.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just fill the array as necessary and terminate with 0
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This allows the removal of CONFIG_INPUT from saa7134, and
helps to create a better Kconfig dependency hierarchy.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The tda8425 initialization function sets up the inputmap for riva boards.
After some digging I discovered that this was for the V4L rivatv driver
that is found on sourceforge. This driver hasn't been maintained since the
last 5 years and will no longer work with the current v4l framework.
So we can safely remove this.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The only reason for keeping I2C_HW_SAA7134 is to allow setting a
per-device polling interval. Just move this info to the platform
data, allowing drivers to change it per device, where needed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move the cx88 specific initialization for Hauppauge XVR remotes
into cx88-input, removing the need for test it inside ir-kbd-i2c.
The reference at cx88 for this symbol, at:
drivers/media/video/cx88/cx88-i2c.c: core->i2c_adap.id = I2C_HW_B_CX2388x;
drivers/media/video/cx88/cx88-vp3054-i2c.c: vp3054_i2c->adap.id = I2C_HW_B_CX2388x;
Can't be removed yet, since lirc-i2c still uses it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Removed the BKL from usbvision.
There was an initialization bug as well where the i2c bus was registered twice.
Although when the BKL was present no oops was generated, I did run into
other i2c problems. Now that I protect against duplicate i2c registration
that bug is now gone as well.
But trying to disconnect the USB cable while someone is still using the device
still leads to a crash.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove a hack in the tuner code for the mxb board. This hack is no longer
needed since the tuner is now probed on its correct address as specified
by the mxb driver.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
