- 21 Oct, 2010 40 commits
-
-
Mauro Carvalho Chehab authored
drivers/media/video/em28xx/em28xx-video.c: In function ‘vidioc_s_register’: drivers/media/video/em28xx/em28xx-video.c:1617: warning: unused variable ‘rc’ Signed-off-by:Mauro Carvalho Chehab <mchehab@redhat.com>
-
Hans Verkuil authored
Signed-off-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
The initial em28xx std (PAL) was not passed on to the subdevs. This led to these tvp5150 kernel log errors when running v4l2-ctl --all: tvp5150 0-005c: VBI can't be configured without knowing number of lines The reason was that tvp5150 was still using its own internal default: STD_ALL. Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
Signed-off-by:
-
Hans Verkuil authored
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 authored
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 authored
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 authored
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 authored
The get_unmapped_area file operation is unused. Remove. Signed-off-by:
-
Hans Verkuil authored
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:
-
Mauro Carvalho Chehab authored
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 authored
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 authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Don't do double mutex_unlock when reading a stream at bttv_poll. Signed-off-by: -
Mauro Carvalho Chehab authored
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 authored
Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Anatolij Gustschin authored
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:
-
Arnd Bergmann authored
The bt8xx driver only uses the big kernel lock in its dst_ca_ioctl function and never to serialize against other code, so we can trivially replace it with a private mutex. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The dvb core only uses the big kernel lock in the open and ioctl functions, which means it can be replaced with a dvb specific mutex. Fortunately, all the ioctl functions go through dvb_usercopy, so we can move the serialization in there. Signed-off-by:
-
Joe Perches authored
Just fill the array as necessary and terminate with 0 Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Andy Shevchenko authored
Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Jean Delvare authored
Code in function cx22702_set_tps() can be slightly simplified. Apparently gcc was smart enough to optimize it anyway, but it can't hurt to make the code more readable. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Steven Toth <stoth@kernellabs.com> Signed-off-by:
-
Jean Delvare authored
The init sequence never changes so it can be marked const. Likewise, cx22702_ops is a template and can thus be made read-only. Signed-off-by:
-
Jean Delvare authored
Calling the same functions in if/else or switch/case branches is inefficient. Refactor the code for a smaller binary and increased readability. Signed-off-by:
-
Mauro Carvalho Chehab authored
warning: (VIDEO_GO7007 && STAGING && !STAGING_EXCLUDE_BUILD && VIDEO_DEV && PCI && I2C && INPUT && BKL && SND || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) warning: (VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) Signed-off-by: -
Mauro Carvalho Chehab authored
This allows the removal of CONFIG_INPUT from saa7134, and helps to create a better Kconfig dependency hierarchy. Signed-off-by: -
Mauro Carvalho Chehab authored
Signed-off-by: -
Hans Verkuil authored
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:
-
Jean Delvare authored
These variables are either unconditionally set right afterward, or already set to 0 by kzalloc. Signed-off-by:
-
Jean Delvare authored
* Avoid temporary variables. * Optimize success paths. * Make error messages consistently verbose. Signed-off-by:
-
Thomas Gleixner authored
Get rid of init_MUTEX[_LOCKED]() and use sema_init() instead. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Jarod Wilson authored
Prompted by Red Hat bugzilla #633023 Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Jarod Wilson authored
Currently, they get set up with the pad keytable, which they can't actually use at all. Also add another variant of volume scancodes from another 0xffdc device, and properly set up the 0x9e 0xffdc device as an iMON VFD w/MCE proto IR. Based on data and a prior patch from Anders Eriksson on the lirc list. Signed-off-by:
-
Jarod Wilson authored
Lest we get our keycodes wrong... Thus far, in practice, I've not found it to actually matter, but its one of the issues raised in https://bugzilla.kernel.org/show_bug.cgi?id=16351 that wasn't addressed by converting to using native IR keydown/up functions. Signed-off-by:
-
David Härdeman authored
This is a stab at separating the mouse (and front panel/knob) events out to a separate input device. This is necessary in preparation for the next patch which makes the rc-core input dev opaque to rc drivers. I can't verify the correctness of the patch beyond the fact that it compiles without warnings. The driver has resisted most of my attempts at understanding it properly...for example, the double calls to le64_to_cpu() and be64_to_cpu() which are applied in imon_incoming_packet() and imon_panel_key_lookup() would amount to a bswab64() call, irregardless of the cpu endianness, and I think the code wouldn't have worked on a big-endian machine... - Minor alterations to apply with minimal core IR changes - Use timer for imon keys too, since its entirely possible for the receiver to miss release codes (either by way of another key being pressed while the first is held or by the remote pointing away from the recevier when the key is release. yes, I know, its ugly). - Bump driver version number, since this is a fairly significant change (for the much much better). Tested successfully w/an imon knob receiver. Signed-off-by:
David Härdeman <david@hardeman.nu> Signed-off-by:
-
Jarod Wilson authored
The imon driver currently reimplements its own version of ir_keyup (along with key release timer functionality also already present in the core IR code). A follow-up imon patch will make use of ir_keyup and the IR stack's key release code. Trivial extraction from David Härdeman's pending rc-core merge and device interface abstraction patchset to facilitate merging a patch based on his imon input dev split patch ahead of the larger churn, which is slated for post-2.6.37-rc1 (after Dmitry's large keycode patches are merged in mainline). Signed-off-by:
-
