[media] cx231xx: remove a printk warning at -avcore and at -417
drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’
drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’
[media] cx231xx: Fix vblank/vactive line counts for PAL/SECAM
Adjust the vblank and vactive counts so that they don't throw an error in
cx25840's set_std call (we did an equivalent change for NTSC when we got the
scaler working).
[media] cx231xx: properly set active line count for PAL/SECAM
The cx231xx_do_mode_ctrl_overrides() function was not touching the vactive line
count for PAL/SECAM modes, which in some use cases results in it being left in
the chip default state of 480 (NTSC).
Explicitly set the values, as is already done for NTSC.
[media] cx231xx: remove board specific check for Colibri configuration
The cx231xx_set_Colibri_For_LowIF() function is only ever called if the tuner
has a DIF (see vidioc_s_frequency() in cx231xx-video.c). Hence, we do not
need to do a board specific check in this function.
[media] cx231xx: Make the DIF configuration based on the tuner not the board id
The current code was deciding whether a DIF was present based on the board
profile. However, this is just another thing for someone to get wrong when
adding new boards. Make the decision based on the tuner instead, so that a
developer adding new boards only needs to specify which tuner the device has.
Of course, the first time somebody adds a board with a tuner other than xc5000
or tda18271, he/she will need to add another line for that tuner. But we
provide a friendly message in dmesg to let them know that.
Nobody is ever going to implement an i2c based IR controller on a bridge that
has an onboard universal IR receiver. This stuff was all copied from em28xx,
which has old enough versions of the chip that some didn't have onboard IR.
Remove the stubs related to i2c based IR (keeping the cx231xx-input code).
[media] cx231xx: make output mode configurable via the board profile
Extend the board profile structure to allow configuration of the output mode.
Right now they are all doing VIP 1.1 format, but we have a board that needs
ITU656 format (which hasn't been checked in yet).
[media] cx231xx: Add initial support for Hauppauge USB-Live2
Add initial support for the Hauppauge USBLive 2 (2040:c200). Note that I
had to copy a bunch of the case statements used for the Conexant video grabber
reference design (which also doesn't have a tuner). This will likely need to
be refactored out into the board profile.
[media] cx231xx: set correct i2c port for Exeter tuner
The tuner is on i2c port 3 just like all the reference designs. Having it
improperly set to port #1 causes the tuner initialization to fail when enabling
the device.
[media] cx231xx: set standard tune to last known frequency when switching inputs
If switching to a tuner input, reset the standard and tune to the last known
frequency. We need to do this in particular for this bridge since the tuner
gets powered down when captuing on the composite or s-video inputs.
[media] cx231xx: Remove hack which puts device into bulk mode
Remove a hack which was jammed into s_input to force the device into bulk mode
at runtime (an abuse of the API). If this sort of functionality is actually
needed (aside from the existing "transfer_mode" modprobe variable), a patch
can be submitted which makes use of a private control.
[media] cx231xx: Set the power mode instead of using the digital mux GPIOs
The Exeter hardware design does not use GPIOs to manage whether its in
digital mode or analog mode, but we need to setup the power control properly.
For that board, setup power control and remove the mux select call. It is
highly likely that this change could be used by other boards as well, which
would make power management cleaner (fixing known issues transitioning between
analog and digital mode).
[media] cx231xx: do not call video_mux as part of isoc setup
You cannot call the video_mux routine from within the isoc setup, because that
code is shared with the digital isoc handler. This was causing the GPIOs and
power control to be put into the wrong state when starting up digital mode.
We need to clear out the field before setting individual bits, or else we end
up with a union of whatever was there and what we are trying to set. For
example, switching to digital mode ends up being 0x30 instead of 0x10 if we
were previously in analog tv mode.
Move the responsibility for setting up the horizontal and vertical scalers
entirely to the cx25840 driver. The cx231xx-avcore was actually programming
garbage into the HSCALE_CTRL and VSCALE_CTRL registers (because of differences
in how the em28xx driver worked, which the cx231xx driver was derived from).
The net effect is that the scaler now works properly (tested with both PAL
and NTSC under mplayer and tvtime).
This patch also gets rid of cx25840 errors showing up in dmesg which say
"720x480 is not a valid size" (since we now properly setup the size of the
active video area).
[media] cx231xx: remove board specific initialization
There is no need for a switch statement here. Use the contents of the board
profile to dictate the tuner driver and i2c address. Eventually if a board
ever comes around which has a different i2c bus than #1, well that should be a
field in the board profile as well.
[media] cx231xx: Ensure VBI fields are sent in the correct order
The current code was sending one videobuf per field (despite having specified
V4L2_FIELD_SEQ_TB during setup). As a result, application which used the
read() interface would work, except they would sometimes have the fields
reversed (depending on the luck of which field the device was on when the
application started VBI capture). The net effect was that CC decoding would
only work about 50% of the time.
Restructure the VBI code a bit so that works like all the other drivers, such
that both fields are delivered in a single videobuf buffer, which ensures that
they are always received in a predictable order.
[media] Use smaller i2c transaction size with 18271 tuner
Configure the tda18271 to use a smaller transaction size by default, which
works around some sort of i2c bug in the Polaris driver (which needs to be
debugged).
This should be safe for other boards (being in tuner-core means it will be
enabled by default), although testing needs to be done.
[media] cx231xx: fix race condition in DVB initialization
Fix case where analog calls come in while the DVB side of the board is still
initializing. This patch is actually just an exact port of the same patch
made by Mauro to em28xx in hg rev 14762.
Ruslan Pisarev [Mon, 27 Sep 2010 13:01:36 +0000 (10:01 -0300)]
[media] Staging: cx25821: fix braces and space coding style issues
Errors found by the checkpatch.pl tool.
[mchehab@redhat.com: merged a series of CodingStyle cleanup patches for cx25851. They're all from the same author, and patches the same driver] Signed-off-by: Ruslan Pisarev <ruslan@rpisarev.org.ua> Cc: Palash Bandyopadhyay <Palash.Bandyopadhyay@conexant.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Daniel Drake [Fri, 24 Sep 2010 17:17:17 +0000 (14:17 -0300)]
[media] cafe_ccic: Fix hang in command write processing
This patch, which basically reverts 6d77444ac, fixes an occasional
on-boot or on-capture hang on the XO-1 laptop.
It seems like the cafe hardware is flakier than we thought and that in
some cases, the commands get executed but are never reported as completed
(even if we substantially increase the delays before reading registers).
Reintroduce the 1-second CAFE_SMBUS_TIMEOUT to catch and avoid this
strange hardware bug.
Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Pete Eberlein [Thu, 23 Sep 2010 17:43:41 +0000 (14:43 -0300)]
[media] go7007: MJPEG buffer overflow
The go7007 driver has a potential buffer overflow and pointer corruption
bug which causes a crash while capturing MJPEG. The motion detection
(MODET) active_map array can be overflowed by JPEG frame data that
emulates a MODET start code. The active_map overflow overwrites the
active_buf pointer, causing a crash.
The JPEG data that emulated MODET start code was being removed from the
output, resulting in garbled JPEG frames. Therefore ignore MODET start
codes when MODET is not enabled.
Signed-off-by: Pete Eberlein <pete@sensoray.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I added a code to the driver to force it to produce a warning. This
were intended to remind me about a very bad hack. I never found a way
to workaround. So, instead of those warnings:
drivers/staging/tm6000/tm6000-core.c: In function ‘tm6000_init_analog_mode’:
drivers/staging/tm6000/tm6000-core.c:328: warning: ISO C90 forbids mixed declarations and code
Let's document the issue and hope if someone with the support of the vendor
might fix it.
[media] lirc_igorplugusb: Fix a compilation waring
drivers/staging/lirc/lirc_igorplugusb.c: In function ‘usb_remote_probe’:
drivers/staging/lirc/lirc_igorplugusb.c:393: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
[media] lirc: Make struct file_operations pointer const
struct file_operations was made const in the drivers, but not in struct
lirc_driver:
drivers/staging/lirc/lirc_it87.c:365: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_parallel.c:571: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_serial.c:1073: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_sir.c:482: warning: initialization discards qualifiers from pointer target type
drivers/staging/lirc/lirc_zilog.c:1284: warning: assignment discards qualifiers from pointer target type
V4L/DVB: tm6000: Fix warnings due to a small array size
drivers/staging/tm6000/tm6000-stds.c:101: warning: excess elements in array initializer
drivers/staging/tm6000/tm6000-stds.c:101: warning: (near initialization for ‘tv_stds[0].common’)
drivers/staging/tm6000/tm6000-stds.c:160: warning: excess elements in array initializer
drivers/staging/tm6000/tm6000-stds.c:160: warning: (near initialization for ‘tv_stds[1].common’)
drivers/staging/tm6000/tm6000-stds.c:219: warning: excess elements in array initializer
drivers/staging/tm6000/tm6000-stds.c:219: warning: (near initialization for ‘tv_stds[2].common’)
drivers/staging/tm6000/tm6000-stds.c:336: warning: excess elements in array initializer
drivers/staging/tm6000/tm6000-stds.c:336: warning: (near initialization for ‘tv_stds[4].common’)
V4L/DVB: videobuf-dma-sg: Fix a warning due to the usage of min(PAGE_SIZE, arg)
drivers/media/video/videobuf-dma-sg.c: In function ‘videobuf_pages_to_sg’:
drivers/media/video/videobuf-dma-sg.c:119: warning: comparison of distinct pointer types lacks a cast
drivers/media/video/videobuf-dma-sg.c:120: warning: comparison of distinct pointer types lacks a cast
V4L/DVB: gspca - sonixj: Bad detection of the end of image
The 'end of image' block may be splitted between two ISOC packets.
This case was not tested, so, some images could be lost and concatenated
to previous one(s), raising 'frame overflow' errors.
Dmitri Belimov [Mon, 20 Sep 2010 20:07:15 +0000 (17:07 -0300)]
V4L/DVB: tm6000+audio
I rework my last patch for audio and now audio works well. This patch
can be submited to GIT tree Quality of audio now is good for SECAM-DK.
For other standard I set some value from datasheet need some tests.
1. Fix pcm buffer overflow
2. Rework pcm buffer fill method
3. Swap bytes in audio stream
4. Change some registers value for TM6010
5. Change pcm buffer size
for the error message, to help detecting what's going wrong with the
device.
This helps to detect when the driver is using the wrong I2C bus (or have
the i2g gate switch pointing to the wrong place), on devices like cx231xx
that just return 0 on reads to a non-existent i2c device.
Reviewed-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB: soc-camera: allow only one video queue per device
Multiple user-space application instances can open the same video device, but
it only makes sense for one of them to manage the videobuffer queue and set
video format of the device. Restrict soc-camera respectively.
V4L/DVB: V4L2: add a generic function to find the nearest discrete format to the required one
Many video drivers implement a fixed set of frame formats and thus face a task
of finding the best match for a user-requested format. Implementing this in a
generic function has also an advantage, that different drivers with similar
supported format sets will select the same format for the user, which improves
consistency across drivers.
drivers/media/video/em28xx/em28xx-video.c: In function ‘vidioc_s_register’:
drivers/media/video/em28xx/em28xx-video.c:1617: warning: unused variable ‘rc’
Hans Verkuil [Sun, 26 Sep 2010 12:01:26 +0000 (09:01 -0300)]
V4L/DVB: videobuf: add queue argument to videobuf_waiton()
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>
Hans Verkuil [Mon, 20 Sep 2010 20:39:46 +0000 (17:39 -0300)]
V4L/DVB: videobuf: add ext_lock argument to the queue init functions
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>
Hans Verkuil [Mon, 20 Sep 2010 20:24:30 +0000 (17:24 -0300)]
V4L/DVB: videobuf: prepare to make locking optional in videobuf
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>
Hans Verkuil [Sun, 26 Sep 2010 11:47:38 +0000 (08:47 -0300)]
V4L/DVB: v4l2: add core serialization lock
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>
Hans Verkuil [Sun, 26 Sep 2010 11:16:56 +0000 (08:16 -0300)]
V4L/DVB: v4l2-dev: after a disconnect any ioctl call will be blocked
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.
V4L/DVB: Deprecate cpia driver (used for parallel port webcams)
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.
V4L/DVB: bttv-driver: document functions using mutex_lock
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
V4L/DVB: v4l: fsl-viu.c: add slab.h include to fix compile breakage
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.
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.
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.
Jean Delvare [Fri, 10 Sep 2010 13:36:37 +0000 (10:36 -0300)]
V4L/DVB: cx22702: Simplify cx22702_set_tps()
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: Mauro Carvalho Chehab <mchehab@redhat.com>
projects / linux-beck.git / log