V4L/DVB (13385): gspca - pac7302: Add red and blue balance control.
The valid values for these controls are 0..3 (lower two bits) which was
identified by trial and error on Labtec Webcam 2200 (USB ID 093a:2626).
The upper 6 bits are ignored on page 0, registers 0xc5 and 0xc7 by the camera.
The usb_control_msg() can fail any time. Only continue writing
sequence if there was no error with the previous write. If there
was any problem stop sending URBs and propagate the error to the
gspca_main.
where sizeof(cam->input_physname) returns length of cam->input_phisname
without length for null-symbol. But this parameter must be - "maximum
numbers of bytes to copy", i.e.:
sizeof(cam->input_physname)-strlen(cam->input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
where sizeof(cam->input_physname) returns length of cam->input_phisname
without length for null-symbol. But this parameter must be - "maximum
numbers of bytes to copy", i.e.:
sizeof(cam->input_physname)-strlen(cam->input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
Like in drivers/hid/usbhid/hid-core.c:
1152 usb_make_path(dev, hid->phys, sizeof(hid->phys));
1153 strlcat(hid->phys, "/input", sizeof(hid->phys));
Found by Linux Driver Verification Project.
Use strlcat instead of strncat.
Signed-off-by: Alexander Strakh <strakh@ispras.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jonathan Corbet [Tue, 17 Nov 2009 22:43:41 +0000 (19:43 -0300)]
V4L/DVB (13377): make struct videobuf_queue_ops constant
The videobuf_queue_ops function vector is not declared constant, but
there's no need for the videobuf layer to ever change it. Make it const
so that videobuf users can make their operations const without warnings.
Signed-off-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB (13368): af9015: support for Sveon STV20 Tuner USB DVB-T HDTV
Add USB ID 1b80:e39d for Sveon STV20 Tuner USB DVB-T HDTV.
Signed-off-by: Ignacio de Miguel Diaz <imigueldiaz@gmail.com> Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:22:02 +0000 (18:22 -0300)]
V4L/DVB (13360): stv090x: fix the calculation of the r divider in stv6110x_set_frequency
It had always the value 3 no matter what frequency was given.
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:20:54 +0000 (18:20 -0300)]
V4L/DVB (13359): stv090x: adds corrections of some register values
While here, also do some blind scan related fixes.
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:19:54 +0000 (18:19 -0300)]
V4L/DVB (13358): stv090x: add an additional check for packet delineator lock in stv090x_read_status in case of a tuned DVB-S2 signal
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:18:53 +0000 (18:18 -0300)]
V4L/DVB (13357): stv090x: adds an additional check for signal presence based on AGC1
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:17:45 +0000 (18:17 -0300)]
V4L/DVB (13356): stv090x: fixes signal lock logic
This patch contains several fixes for the stv090x driver:
- added missing else
- use calculated timeout instead of fixed one
- use correct frequency when doing zigzag scan
- added missing read of GENCFG register
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:16:44 +0000 (18:16 -0300)]
V4L/DVB (13355): stv090x: fixes calculation of AGC2 and uses a different AGC2 threshold for cut 3 chips
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:15:27 +0000 (18:15 -0300)]
V4L/DVB (13354): stv090x: fixes some typos like wrong register or variable names
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:14:00 +0000 (18:14 -0300)]
V4L/DVB (13353): stv090x: fixes STR and SNR calculation and normalizes the value into the 0..0xFFFF range
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:12:48 +0000 (18:12 -0300)]
V4L/DVB (13352): stv090x: fixes errors and typos in register definitions
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andreas Regel [Fri, 13 Nov 2009 21:11:26 +0000 (18:11 -0300)]
V4L/DVB (13351): stv090x: increases search range based on symbol rate
Signed-off-by: Andreas Regel <andreas.regel@gmx.de> Signed-off-by: Manu Abraham <manu@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB (13332): s5h1409: remove a set register that would cause lock to be lost.
On particularly weak signals, changing register 0xab after setting the
interleave mode will cause the FEC lock to get lost (while still holding the
EQ lock). So remove the write entirely, which seems to have had no adverse
effect in either of my ClearQAM environments (and in particular resolves the
customer's reported issue).
Also flip around the order of the amhum optimization and the interleave setup
to be consistent with the windows driver, which has the side-benefit of doing
them both in the same call (since the amhum optimization can only be done once
the interleave setup).
V4L/DVB (13331): mxl5005s: provide ability to override QAM gain for HVR-1600
The HVR-1600 doesn't use the standard mechanism for computing the gain when
in QAM mode, instead always forcing it to be 0x02. Provide the ability to
override the algorithm on a per-board basis.
This change results in an improvement of 0.4-0.6 dB for QAM tuning.
V4L/DVB (13330): s5h1409: properly handle QAM optimization after lock achieved
The sh51409 driver was only doing the QAM optimization a single time, and it
would only occur if you received a lock instantaneously after the tuning
request. Restructure the code so that the optimization occurs once you reach
a signal lock.
Note that this depends on the caller polling for status, but we don't have
much choice at this point without an independent thread monitoring the lock
status. Also, at this point pretty much every application polls for status
lock after doing the tune, so the likelihood of the optimization not occurring
in the real world is pretty low.
The state machine has also been reworked such that setting the interleave mode
is now a dependency of doing the QAM optimization. Before both were mutually
exclusive, which was not consistent with the Windows driver. We now have a
single state machine that controls both.
The changes as-is are only enabled for the HVR-1600. Once the changes are
tested with some of the other boards, this change should be made generic and
the "_legacy" functions should be removed.
V4L/DVB (13329): s5h1409: provide HVR-1600 specific optimizations
Perform some optimization of the register configuration based on a trace
of the HVR-1600 Windows i2c traffic (and consultation with Steven Toth).
Note that some of these values may be able to be moved into the common driver,
but I am holding off on that until they can be tested with other boards.
Marton Nemeth [Thu, 5 Nov 2009 08:35:08 +0000 (05:35 -0300)]
V4L/DVB (13324): gspca - pac7302/pac7311: Handle return value of usb_control_msg().
The function usb_control_msg() can return error any time so at least
warn the user if an error happens. No message is printed in case of
normal operation.
V4L/DVB (13323): gspca - zc3xx: Adjust the exchanges of sensors mi0360soc and pb0330.
- the pb03303x exchanges were the mi0360soc ones
- add the new sensor mi0360soc
- the new exchanges are taken from the info file of the ms-win driver
of the webcams 0ac8:301b and 0ac8:303b (vm30x.inf)
Marton Nemeth [Mon, 2 Nov 2009 11:13:21 +0000 (08:13 -0300)]
V4L/DVB (13300): gspca - pac7302/pac7311: Separate the two subdrivers.
All PAC7311 specific functions remain in pac7311.c. All PAC7302 specific
functions are moved to pac7302.c. The USB device table is also divided into
two parts. This makes it possible to remove the sensor specific decisions
from different functions and also remove sensor infromation from the USB
device table.
The common functions are just copied to both subdrivers. These common
functions can be separated later to a common file or helper module.
Remove struct sd dependency from pac_find_sof() function implementation.
This step prepares separation of pac7302 and pac7311 specific parts of
struct sd.
Peter Huewe [Wed, 4 Nov 2009 18:28:33 +0000 (15:28 -0300)]
V4L/DVB (13288): adding __init/__exit macros to various drivers
Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of the following drivers in media video:
drivers/media/video/ivtv/ivtv-driver.c
drivers/media/video/cx18/cx18-driver.c
drivers/media/video/davinci/dm355_ccdc.c
drivers/media/video/davinci/dm644x_ccdc.c
drivers/media/video/saa7164/saa7164-core.c
drivers/media/video/saa7134/saa7134-core.c
drivers/media/video/cx23885/cx23885-core.c
Cc: Hermann Pitton <hermann-pitton@arcor.de> Acked-by: Steven Toth <stoth@kernellabs.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Acked-by: Andy Walls <awalls@radix.net> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Muralidharan Karicheri <m-karicheri2@ti.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Abylay Ospan [Sun, 1 Nov 2009 21:46:53 +0000 (18:46 -0300)]
V4L/DVB (13271): TS speed check. Logging transport stream speed in Kbits per second
[mchehab@redhat.com: add asm/div64.h and allocate vars only if dvb_demux_speedcheck specified] Signed-off-by: Abylay Ospan <aospan@netup.ru> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the changeset entitled, "tda18271: add support for the set_config method",
the initialization order was changed such that the standard map overrides
were being applied before loading the default standard map, based on the
stepping of the silicon. This changeset restores the proper order by
processing the standard map overrides both within the tda18271_set_config()
and the tda18271_attach() functions, after we read the id register of the
tuner.
Thanks to Michael Obst for his testing, helping me to identify the regression.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Michael Obst <mike.obst@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As pointed out by Hermann Pitton, it turns out that the DTV1000S card's
analog entry made it into the #if 0 flyvideo tweaks in saa7134-cards.c
and is not valid there.
This patch fixes the problem.
Cc: hermann pitton <hermann-pitton@arcor.de> Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Michael Krufky [Sat, 24 Oct 2009 19:42:16 +0000 (16:42 -0300)]
V4L/DVB (13247): tuner-core: dont force every tuner to set frequency at startup
Setting the tuner frequency at the same time as initializing the other devices
on the i2c bus can cause problems on devices that require firmware download or
extensive calibration proceduces during initialization.
This change allows us to prevent the tune at startup for devices that perform
better without it.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans de Goede [Thu, 29 Oct 2009 10:42:30 +0000 (07:42 -0300)]
V4L/DVB (13242): gspca_mr97310a: Add minimum clock divider control
When "shooting" certain (quite rare) scenes, the mr97310's compression is not
effective and it cannot keep up with the data stream. This patch adds a
minimum clock divider control, which influences the maximum framerate,
libv4l will automatically increase this minimum clockdiv control when it
detect the cam cannot keep up.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Roel Kluin [Fri, 23 Oct 2009 10:59:42 +0000 (07:59 -0300)]
V4L/DVB (13241): Cleanup redundant tests on unsigned
The variables are unsigned so the test `>= 0' is always true,
the `< 0' test always fails. In these cases the other part of
the test catches wrapped values.
V4L/DVB (13239): saa7146: fix memory leakage in pagetable-handling
In buffer_release() the previously allocated pagetables are not
freed, which might result in a memory leak in certain application
use-cases, where the frame format is changed from planar format to
non-planar format. The fix explicitely frees the page tables when a
format change is done and when buffer_release() is called.
Signed-off-by: Johann Friedrichs <johann.friedrichs@web.de> Signed-off-by: Michael Hunold <hunold@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
V4L/DVB (13238): v4l2_subdev: rename tuner s_standby operation to core s_power
Upcoming I2C v4l2_subdev drivers need a way to control the subdevice
power state from the core. This use case is already partially covered by
the tuner s_standby operation, but no way to explicitly come back from
the standby state is available.
Rename the tuner s_standby operation to core s_power, and fix tuner
drivers accordingly. The tuner core will call s_power(0) instead of
s_standby(). No explicit call to s_power(1) is required for tuners as
they are supposed to wake up from standby automatically.
I do not think it makes sense any longer for ir-kbd-i2c to reject
devices at unknown I2C addresses. The caller can provide all the
details about how the device should be handled. Having to add new
addresses to ir-kbd-i2c so that they aren't rejected is a pain we
don't need. Unsupported devices will be spotted a few lines later
anyway.
This already lets us unlist 2 addresses (0x7a and 0x2d) for which
handling details are always provided by the caller (saa7134-input).
Hopefully we can remove more in the future.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Fri, 2 Oct 2009 12:48:04 +0000 (09:48 -0300)]
V4L/DVB (13235): saa7134: Complete the IR address list
Google is pretty clear that the HVR 1110 IR chip is always at address
0x71 and the BeholdTV IR chip is always at address 0x2d. This
completes the list of IR device addresses for the SAA7134-based
adapters, and we no longer need to probe any of them.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Fri, 2 Oct 2009 11:47:22 +0000 (08:47 -0300)]
V4L/DVB (13234): IR device at I2C address 0x7a
The i2c core prevents us from probing I2C address 0x7a because it's
not a valid 7-bit address (reserved for 10-bit addressing.) So we must
stop probing this address, and explicitly list all adapters which use
it. Under the assumption that only the Upmost Purple TV adapter uses
this invalid address, this fix should do the trick.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: hermann pitton <hermann-pitton@arcor.de> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Jean Delvare [Fri, 2 Oct 2009 08:47:08 +0000 (05:47 -0300)]
V4L/DVB (13233): i2c_board_info can be local
Recent fixes to the em28xx and saa7134 drivers have been overzealous.
While the ir-kbd-i2c platform data indeed needs to be persistent, the
struct i2c_board_info doesn't, as it is only used by i2c_new_device().
So revert a part of the original fixes, to save some memory.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
cx25840:
Disable 6.5MHz carrier autodetection for PAL, always assume its DK.
Only try to autodetect 6.5MHz carrier for SECAM if user accepts both
system DK and L.
Signed-off-by: Aleksandr V. Piskunov <alexandr.v.piskunov@gmail.com> Reviewed-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mike Isely [Mon, 12 Oct 2009 03:23:37 +0000 (00:23 -0300)]
V4L/DVB (13225): pvrusb2: Report hardware description to kernel log upon initialization
The driver also contains a piece of configuration data that produces a
one line description of the specific hardware being driver
(e.g. "Hauppauge 24xxx", "OnAir", etc). This change generates an
informational message to the kernel log reporting the hardware type
being driven. This is a very useful thing to know when diagnosing
problems.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mike Isely [Mon, 12 Oct 2009 03:21:20 +0000 (00:21 -0300)]
V4L/DVB (13224): pvrusb2: Improve diagnostic info on driver initialization failure
It used to be that the only real detectable reason for the driver to
fail during initialization would be that if the hardware is simply
jammed. However with the advent of the sub-device mechanism in V4L it
is possible now to detect if a sub-device module fails to load
successfully. The pvrusb2 driver does in fact react to this by also
(correctly) failing, however the original diagnostic message "hardware
is jammed" was still being reported. This misleads the user because
in fact it might not actually be a hardware failure. This change adds
logic to tell the difference and then report a more appropriate
message to the kernel log.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>