Attached is a patch which fixes tuning to low frequency channels with
stb0899+tda8261 cards like the KNC TV-Station DVB-S2.
The cause of the issue was a broken if construct, which should have been
an if/else if, so that the setting for the lowest matching frequency is
applied.
Without this patch for example tuning to "arte" on Astra 19.2, 10744MHz
SR22000 failed most times and when it failed the communication between
driver and tda8261 was completely broken.
This problem disappears with the attached patch.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add new USB ID (1b80:e400) for KWorld PlusTV Dual DVB-T Stick (DVB-T 399U).
The model number on the devices sticker label is "KW-DVB-T 399UR".
Signed-off-by: Mart Raudsepp <mart.raudsepp@artecdesign.ee>
Acked-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
These changes were a direct result of using a semantic patch
More information can be found at http://www.emn.fr/x-info/coccinelle/
[mchehab@redhat.com: fix a merge conflict]
Signed-off-by: Stoyan Gaydarov <sgayda2@uiuc.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems from other code that it is the dst_type field rather than the
type_flags field that contains values of the form DST_TYPE_IS...
The type_flags field contains values of the form DST_TYPE_HAS...
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@ struct dst_state E; @@
(
*E.type_flags ==
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
|
*E.type_flags !=
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
)
// </smpl>
Cc: Manu Abraham <abraham.manu@gmail.com>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for Humax/Coex DVB-T USB Stick 2.0 High Speed
which is a very popular tuner sold in Vietnam.
Tested with at least 3 tuners.
Cc: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Pham Thanh Nam <phamthanhnam.ptn@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The changeset 0b17d0ed that aded ASUSTeK P7131 Analog were using
7 spaces instead of tab, probably due to some bad cut-and-paste.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
On VIDEO_M52790 and USB_GSPCA_SN9C20X, instead of tab, it were
using 7 whitespaces at the beginning, probably due to some
cut-and-paste trouble.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Patch solves problem of missed keystrokes on some remote controls,
as reported on http://bugzilla.kernel.org/show_bug.cgi?id=9637 .
Signed-off-by: Andrzej Hajda <andrzej.hajda@wp.pl>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The card includes Intel ce5039(Zarlink zl10039) tuner
and Intel ce6313 (Zarlink zl10313) demod.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The code from Jan D. Louw with some minor changes.
http://article.gmane.org/gmane.linux.drivers.dvb/38163
Tested with TeVii S630 DVB-S USB card by me (Igor)
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Robert P.J. Day for finding this.
Thanks-to: Robert P.J. Day <rpjday@crashcourse.ca>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for the remote control that comes with the Cinergy Hybrid T USB XS
Thanks to Jelle de Jong for providing sample hardware to test with.
Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I updated and simplyfied patch from Zbynek Hrabovsky for recent kernel.
It enables autodetection of card, sound in analog TV , sound in FM radio
and switching between antenna and cable RF input. Radio tuner still
doesn't work, I don't even know how it works. Some guys wrote me that FM
radio works with TV tuner used instead of radio part (symlink video0 ->
radio0).
Cc: Gerd Knorr <kraxel@bytesex.org>
Signed-off-by: Vlastimil Labsky <vlasta.labsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
do_div requires an u64 as the first argument, not a s64.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Acked-by: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use unified lgs8gxx frontend instead of reverse engineered lgs8gl5 frontend.
After this patch, lgs8gl5 frontend could be mark as deprecated.
Future development should base on unified lgs8gxx frontend.
Signed-off-by: David T.L. Wong <davidtlwong@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Error handling code following a kmalloc should free the allocated data.
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We have support for radio on saa7133/35/31e cards with tda8290/8275(a)
and 5.5MHz ceramic filter on the bridge chips since a while.
It was previously not tested, if this card supports it too, but the old
"ghost" radio with wrong filters doesn't work anymore.
Thanks go to Pham Thanh Nam and Laszlo Kustan for reporting it working
on that input.
Signed-off-by: hermann pitton <hermann-pitton@arcor.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Define correct tuner in config. Radio now works fine
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov <d.belimov@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The structure and comments of the I2C part have been adopted to fit to the
USB part.
Some additional cleanups and precisements have been made to the version
detection and checking functionality to clearly separate HW/SW/FW version.
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch supports i2c interface of si470x. The i2c specific part
exists in radio-si470x-i2c.c file and the common part uses
radio-si470x-common.c file. The '#if defined' is inserted inevitably
because of parts used only si470x usb in the common file.
The current driver version doesn't support the RDS.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The si470x_disconnect_check is function to check disconnect state of
radio in common file. The function is implemented in each interface
file.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is for using dev_* macro instead of printk.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch is a preceding work to add the i2c interface of si470x.
The si470x directory includes a common file and usb specific file and
header file.
The part unrelated with usb interface and i2c interface exists in
radio-si470x-common.c file, and The usb specific part exists in
radio-si470x-usb.c file.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
[tobias.lorenz@gmx.net: Small changes, due to new include "linux/smp_lock.h"]
Signed-off-by: Tobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for the STK7700D USB-DVB-Device.
lsusb identifies it as:
idVendor 0x1164 YUAN High-Tech Development Co., Ltd
idProduct 0x1efc
iProduct 2 STK7700D
The device is build into a Samsung R55-T5500 notebook.
Signed-off-by: Pete Hildebrandt <send2ph@googlemail.com>
Signed-off-by: Patrick Boettcher <pboettcher@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restructure the UVC descriptors parsing code to handle multiple streaming
interfaces. The driver now creates a uvc_video_chain instance for each chain
detected in the UVC control interface descriptors, and tries to register one
video device per streaming endpoint.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As a first step towards multiple streaming interfaces support, reorganize the
driver's data structures to cleanly separate video control and video streaming
data.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L2 API (chapter 1.5) states that:
Drivers must implement all input ioctls when the device has one
or more inputs, all output ioctls when the device has one or more outputs.
When the device has any audio inputs or outputs the driver must set the
V4L2_CAP_AUDIO flag in the struct v4l2_capability returned by the
VIDIOC_QUERYCAP ioctl.
So, devices without audio input should return -EINVAL.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There seems to be one superfluos unlock in a poll function. Remove it.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The irq handler will touch memory. Even in the error case some URBs may
complete. Thus no memory must be kfreed before all URBs are killed.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for Zilog Z8F0811 IR transceiver chips on
CX2341[68] based boards to ir-kbd-i2c for both the old i2c binding model
and the new i2c binding model.
Signed-off-by: Andy Walls <awalls@radix.net>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch add support to the cx18 driver for setting up the
Z8F0811/Hauppauge IR Tx/Rx chip with the i2c binding model in newer
kernels.
Signed-off-by: Andy Walls <awalls@radix.net>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch augments the init data passed by bridge drivers to
ir-kbd-i2c, so that the ir_type can be set explicitly, and so
ir-kbd-i2c internal get_key functions can be reused without
requiring symbols from ir-kbd-i2c in the bridge driver.
Signed-off-by: Andy Walls <awalls@radix.net>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Functions which are referenced by their address can't be inlined by
definition.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The au0828-dvb driver uses bulk usb transfers for digital transport,
but the debug reports, "iso xfer already running!\n".
Fix this to report bulk instead of isoc.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This prevents a loop if a permanent error occurs in usb_set_interface().
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patches
gspca - vc032x: Add resolution 1280x1024 for sensor mi1310_soc.
gspca - vc032x: Webcam 041e:405b added and mi1310_soc updated.
will make the preview function not work, so I disable the 1280x1024 resolution
and revert back to the origin mi1310_soc settings.
And, using USB snoop tool on Windows to get the correct i2c commands to
turn on/off the LED flash.
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* use i2c_w instead of reg_w
* return error on failure
* read the correct number of bytes
Signed-off-by: Brian Johnson <brijohn@gmail.com>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
After the i2c subdev changes the ordering of initialization changed,
causing a total loss of previous GPIO settings and a loss of DTV.
The generic firmware loading routine has now changed to preserve
GPIO values if the device is cx23885 based (safety) and I've
moved the GPIO configuration from probe() into the cx23885 init
func which is a little clearer and fixes the bug.
Tested-by: Sohail Syyed <linuxtv@hubstar.net>
Reviewed-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Even devices without ac97 needs to call analog audio setup function, to
properly set xclk and mute/unmute.
Thanks to Angelo Cano <acano@fastmail.fm> for reporting and testing it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There is no point in defining I2C adapter IDs when no code is using
them. As this field might go away in the future, stop using it when
we don't need to.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Replace printing to magically sized temporary buffer with use
of KERN_CONT for continual printing of eeprom registers dump.
Since deb_info is defined as dprintk, which is conditionally defined
to printk without additional parameters, meaning that deb_info is equivalent
to direct printk (without adding KERN_ facility), we can use KERN_DEBUG and
KERN_CONT in there, eliminating the need for sprintf into temporary buffer
with not easily readable/magical size.
Though it's strange, that deb_info definition uses printk without KERN_
facility and callers don't use it either.
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the subdev_s_std() method from the GPIO subdev. It appears it was
used in the past to effect the switch back from radio mode to tuner mode,
but it had a side effect that is improper and against the V4L2 spec, when
you were not in radio mode. Whenever the video stanadrd was changed, the
GPIO audio mux was set back to the tuner audio input, even if you were set
to a Line In input.
Thanks to Ravi A. for doing the troubleshooting to point me right to the
problem.
Reported-by: Ravi A <asvravi@gmail.com>
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Create card parameters array in SDMC DM1105 driver.
It is useful for cards with the same pci id, but different
tuners, lnb power control circuits, etc.
Signed-off-by: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
At least one MT6227 model crashes when receiving a GET_DEF request on the
video probe control. As the various models can't be told apart based on the
descriptors, add a PROBE_DEF quirk to avoid sending the GET_DEF request and
enable the quirk for all models.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
. added code to print an error message when buffer is too small to hold frame
data, that is better than just a hard crash. Tested using MAX_FRAME_SIZE =
50000, lots of error messages appeared in /var/log/messages but no crash.
. removed line "f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;" in
zr364xx_vidioc_try_fmt_vid_cap, it should not be there.
. changes to improve performance (or at least not hurt it): removed some
unneeded debug messages; added macro FULL_DEBUG to enable debug messages in
performance critical places, this macro is disabled by default; removed "if
(frm->lpvbits == NULL)..." in zr364xx_read_video_callback because after
analisying the source code I concluded it will always results to false, so it
is not needed.
. some small code reorganization.
Signed-off-by: Lamarque V. Souza <lamarque@gmail.com>
Signed-off-by: Antoine Jacquet <royale@zerezo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements changing resolution in zr364xx_vidioc_s_fmt_vid_cap for
zr364xx driver. This version is synced with v4l-dvb as of 20/Jul/2009. Tested
with Creative PC-CAM 880.
OBS: I had to increase MAX_FRAME_SIZE to prevent a hard crash in my notebook
(caps lock blinking) when testing with mplayer, which automatically sets
resolution to the maximum (640x480). Maybe we should add code to auto-detect
frame size to prevent this kind of crash in the future.
Signed-off-by: Lamarque V. Souza <lamarque@gmail.com>
Signed-off-by: Antoine Jacquet <royale@zerezo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add CAM presence checkout during CiMax init for NetUP card.
CAM presence checkout is needed after power on PC.
Signed-off-by: Igor M. Liplianin <liplianin@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In automatic mode every stop event on SDA line ends repetition.
However, in NetUP Dual card on the same i2c bus we have several devices.
If someone using both adapters to lock simultaneously or working with CAM interface
during lock procedure, it lead to end repetition prematurely quite often.
Set stv0900 i2c repeater to manual mode prevents such situation.
Signed-off-by: Abylay Ospan <aospan@netup.ru>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cx23885: Add support for ATSC/QAM on Hauppauge HVR-1850
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
... improves readability and routes the calls through a specific single point.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The encoder driver has hardcoded GPIO bits set for the HVR1800, regardless
of whether it's being used by a HVR1800 or not. I've implemented some generic
GPIO manipulation routines and I'm calling them only when appropriate.
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The dvb-pll code should do the same thing that
alps_tdee4_stv0297_tuner_set_params() was doing. Except the dvb-pll code
will check for tuner presence when attaching, while the old code didn't.
This tuner appears to not be behind the stv0297's I2C gate but is instead
on a different I2C adapter provided by the flexcop chip. The old code
would turn the I2C gate off each time the tuner was used. I've changed it
to turn the gate off when the tuner is attached and then disable the gate
control function. This should result in the gate staying off, which should
be even better.
[hverkuil@xs4all.nl: fix compile error]
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The code in skystar23_samsung_tbdu18132_tuner_set_params() and
samsung_tbmu24112_tuner_set_params() is equivalent to what the dvb-pll code
does. There could be an issue because the dvb-pll code will probe to check
for the tuner, while the previous code didn't do any checks.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The code in samsung_tdtc9251dh0_calc_regs() is equivalent to what dvb-pll's
code does.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
No datasheet, data take from code in flexcop driver. That code rounded
down the divisor rather than rounding to nearest, which was probably not
intentional and the dvb-pll code will round to nearest.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tuner parameters determined from code in flexcop driver. That code rounded
the divisor down instead of to the nearest value. This was probably not
intentional and the dvb-pll version will round to nearest.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Tuner parameters taken from flexcop driver. This PLL has a 17 bit divisor
while the dvb-pll driver is designed for 15 bit divisors. It's not a
problem as 15 bits is enough for the tuner's entire range. But if a larger
range was wanted, it could be done by adding additional bands with the
extra divisor bits appearing as band switch bits.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
No datasheet, tuner data comes from code in flexcop driver. This tuner is
also used on the AVerTV 771 supported by the bttv driver, but that code
uses a different tuner configuration, which is surprising.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by
converting the driver to use videobuf. This version is synced with v4l-dvb as
of 15/Jul/2009.
Tested with Creative PC-CAM 880.
It basically:
. implements V4L2_CAP_STREAMING using videobuf;
. re-implements V4L2_CAP_READWRITE using videobuf;
. copies cam->udev->product to the card field of the v4l2_capability struct.
That gives more information to the users about the webcam;
. moves the brightness setting code from before requesting a frame (in
read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is
executed only when the application requests a change in brightness and
not before every frame read;
. comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype +
libv4l do not work.
This patch fixes zr364xx for applications such as mplayer,
Kopete+libv4l and Skype+libv4l can make use of the webcam that comes
with zr364xx chip.
Signed-off-by: Lamarque V. Souza <lamarque@gmail.com>
Signed-off-by: Antoine Jacquet <royale@zerezo.com>
[mchehab@redhat.com: fix the lack of linux/version.h]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Values for 'pid' range from 0 to 0x1fff. Therefore 'feed->pid' can never
be equal to both 'pid' and 0x2000. This makes the continue statement have
no effect.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
DMX_ADD_PID allows to add multiple PIDs to a transport stream filter
previously set up with DMX_SET_PES_FILTER and output=DMX_OUT_TSDEMUX_TAP.
DMX_REMOVE_PID is used to drop a PID from a filter.
These ioctls are to be used by readers of /dev/dvb/adapterX/demuxY. They
may be called at any time, i.e. before or after the first filter on the
shared file descriptor was started.
They make it possible to record multiple services without the need to de-
or re-multiplex TS packets.
To accomplish this, dmxdev_filter->feed.ts has been converted to a list
of struct dmxdev_feeds, each containing a PID value and a pointer to a
struct dmx_ts_feed.
Signed-off-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the past, some devices with saa711x had their parameters controlled
directly inside em28xx driver, instead of using their proper module for
it.
Due to that, the ac97 controls were mixed with saa711x ones.
Older patches removed all saa711x controls, but we still need to control
ac97 devices on em28xx, since we don't have a separate v4l2 device for
it.
The proper way to address is to create a separate ac97 v4l2 device.
While we don't have it, we should clean up the code to allow having a
better view of what is part of em28xx core code and what's due to ac97
control inside it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As em28xx chip has nothing to do with volume/mute controls, rename those
controls to properly indicate that they control the companion AC97 chip
that it is inside the boards with this chip.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
lgs8gxx: add lgs8g75 demodulator support
Signed-off-by: David T.L. Wong <davidtlwong@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- call a new subdriver function 'isoc_init' before chosing the first
alternate setting.
- call a new subdriver function 'isoc_nego' when submitting the URBs failed.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Only the back sensor (mi1320_soc) is usable.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
My initial change left the AVerMedia UtlraTV 1500MCE card entry out of the
list of cards to check during the probe. This change adds it to the
ivtv_card_list[].
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add a routine for dumping the EEPROM of the MPC718. It is generic enough
to use for other cards in the future that may have an EEPROM.
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
input, inp and i are unsigned. When negative they are wrapped and caught by the
other test.
Cc: Andy Walls <awalls@radix.net>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some Aveo Technology USB 2.0 Camera (1871:0306) revisions seem to require the
PROBE_MINMAX quirk. As the camera supports uncompressed YUYV data only, it's
safe to set the quirk even if not strictly required for all models. Update the
device entry in the device IDs list.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
To make UVC constants accessible by a future UVC gadget driver, move them from
drivers/media/video/uvc/uvcvideo.h to include/linux/usb/video.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Those constants are not used anymore, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In preparation to moving UVC constants to a public location, prefix all
constants with UVC_ to avoid namespace clashes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
uvcvideo.h redefines class-specific descriptor types already present in
usb/ch9.h. Remove the duplicated definitions and use the ones from usb/ch9.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We should call em28xx_ir_init(dev) only when disable_ir is true.
Signed-off-by: Shine Liu <shinel@foxmail.com>
Reviewed-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The order of indexes is reversed
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Antoine Jacquet <royale@zerezo.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[mchehab@redhat.com: fix merge conflict and a few CodingStyle issues]
Signed-off-by: Steve Gotthardt <gotthardt@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Previous changesets broke Hauppauge devices and their GPIO configurations.
This changeset restores the LED & LNA functionality.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch modifies the SuperH Mobile CEU driver to support
Runtime PM. Driver callbacks for Runtime PM are empty because
the device registers are always re-initialized after
pm_runtime_get_sync(). The Runtime PM functions replaces the
clock framework module stop bit handling in this driver.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch changes most frontend drivers to allocate their state structure via
kzalloc and not kmalloc. This is done to properly initialize the
embedded "struct dvb_frontend frontend" field, that they all have.
The visible effect of this struct being uninitalized is, that the member "id"
that is used to set the name of kernel thread is totally random.
Some board drivers (for example cx88-dvb) set this "id" via
videobuf_dvb_alloc_frontend but most do not.
So I at least get random id values for saa7134, flexcop and ttpci based cards.
It looks like this in dmesg:
DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S)
The related kernel thread then also gets a strange name
like "kdvb-ad-1-fe--1".
Cc: Michael Krufky <mkrufky@linuxtv.org>
Cc: Steven Toth <stoth@linuxtv.org>
Cc: Timothy Lee <timothy.lee@siriushk.com>
Cc: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
Acked-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It tested the value of stk_sizes[i].m before checking whether i was in range.
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restore support for digital tuning caused by regression during introduction
of disable_i2c_gate parameter to zl10353 driver.
Thanks to user "Xwang" for reporting the problem and testing the fix
Cc: Xwang <xwang1976@email.it>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The v4l core supplies default handlers for G_STD and G_PARM. However, both
default handlers are buggy.
This patch fixes the following:
1) If no g_std is supplied and current_norm == 0, then this driver does not
support TV video standards (e.g. a radio or webcam driver). Return
-EINVAL. This ensures that there is no bogus VIDIOC_G_STD support for
such drivers.
2) The default VIDIOC_G_PARM handler used current_norm instead of first
checking if the driver supported g_std and calling that to get the norm.
It also didn't check if current_norm was 0, since in that case the driver
does not support TV standards (or no standard was set at all) and the
default handler should return -EINVAL.
Note that I am very unhappy with these default handlers: I think they
basically behave like some very strange and unexpected side-effect.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers should either set current_norm or supply a g_std callback.
The hdpvr driver does neither. Since it initializes to a 60 Hz format
I've initialized the current_norm to NTSC | PAL_M | PAL_60 which is the
60 Hz subset of tvnorms.
Cc: Janne Grunau <j@jannau.net>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The .buf_queue() V4L2 driver method is called under
spinlock_irqsave(q->irqlock,...), don't take the lock again inside the
function.
Reported-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix build errors in zr364xx by adding selects:
zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon'
zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf'
zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf'
zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf'
zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs'
zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy'
zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free'
zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock'
zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper'
zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream'
zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one'
zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free'
zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init'
zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff'
zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc'
zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff'
drivers/built-in.o: In function `free_buffer':
zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free'
drivers/built-in.o: In function `zr364xx_open':
zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init'
drivers/built-in.o: In function `read_pipe_completion':
zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Register 0x13 seems to be a sort of image control, maybe gamma, white
level or black level. Lower values produce better images, while higher
values increases the contrast and shifts colors to green. 0xff produces
a black image. This register is not Silvercrest-specific, so its code
should be moved to a better place.
If this register is left alone, a random value can be found at the
register, producing weird results.
While here, let's remove register 0x0d, as it had no noticed effect at
the image.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Silvercrest mt9v011 sensor produces a 640x480 image. However,
previously, the code were getting only half of the lines and merging two
consecutive frames to "produce" a 640x480 image.
With the addition of progressive mode, now em28xx is working with a full
image. However, when the number of lines is bigger than 240, the
beginning of some odd lines are filled with blank.
After lots of testing, and physically checking the device for a Xtal, it
was noticed experimentally that mt9v011 is using em28xx XCLK as its
clock. Due to that, changing XCLK value changes the maximum speed of the
stream.
At the tests, it were possible to produce up to 32 fps, using a 30 MHz
XCLK. However, at that rate, the artifacts happen even at 320x240. Lower
values of XCLK produces artifacts only at 640x480.
At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is
possible to see an invalid sucession of artifacts with this pattern:
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(where the dots represent the blanked pixels)
So, it seems that a waveform in the format of a ramp is interferring at
the image.
The cause of this interference is currently unknown. Some possibilities
are:
- electrical interference (maybe this device is broken?);
- some issue at mt9v011 programming;
- some bug at em28xx chip.
So, for now, let's be conservative and use a value of XCLK that we know
for sure that it won't cause artifacts.
As I'm waiting for more of such devices with different em28xx chipset
revisions, I'll have the opportunity to double check the issue with
other pieces of hardware.
Later patches can vary XCLK depending on the vertical resolutions, if a
proper fix is not discovered.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_pre_card_setup() is meant to contain board-specific initialization. Also,
as autodetection sometimes occur only after having i2c bus enabled, this
function may need to be called later.
Moving those setups to happen outside the function avoids calling it twice without
need and without duplicating output lines at dmesg.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We don't know the xtal frequency of Silvercrest, but we need to have
some value in order to allow controlling the frame rate frequency. The
value is probably still wrong, since the manufacturer announces this
device as being capable of 30fps, but the maximum we can get is
13.5 fps.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to historical reasons, em28xx driver gets two consecutive frames and
fold them into an unique framing, doing interlacing. While this works
fine for TV images, this produces two bad effects with webcams:
1) webcam images are progressive. Merging two consecutive images produce
interlacing artifacts on the image;
2) since the driver needs to get two frames, it reduces the maximum
frame rate by two.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by hermann pitton <hermann-pitton@arcor.de>, some devices
has a different chip id for em2710 (likely the older ones):
em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0)
em28xx #0: Identified as EM2710/EM2750/EM2751 webcam grabber (card=22)
em28xx #0: em28xx chip ID = 17
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
