- 19 Apr, 2012 4 commits
-
-
Michael Krufky authored
Rather than loading firmware specific for the xtal frequency, just use the standard firmware and set the xtal frequency after firmware upload. The modified firmware will never be released, so we're better off merging this now rather than waiting for v3.5. Signed-off-by:
Michael Krufky <mkrufky@kernellabs.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Guennadi Liakhovetski authored
Fix the following compilation failure: linux-2.6/drivers/media/video/mt9m032.c: In function '__mt9m032_get_pad_crop': linux-2.6/drivers/media/video/mt9m032.c:337: error: implicit declaration of function 'v4l2_subdev_get_try_crop' linux-2.6/drivers/media/video/mt9m032.c:337: warning: return makes pointer from integer without a cast linux-2.6/drivers/media/video/mt9m032.c: In function '__mt9m032_get_pad_format': linux-2.6/drivers/media/video/mt9m032.c:359: error: implicit declaration of function 'v4l2_subdev_get_try_format' linux-2.6/drivers/media/video/mt9m032.c:359: warning: return makes pointer from integer without a cast linux-2.6/drivers/media/video/mt9m032.c: In function 'mt9m032_probe': linux-2.6/drivers/media/video/mt9m032.c:767: error: 'struct v4l2_subdev' has no member named 'entity' linux-2.6/drivers/media/video/mt9m032.c:826: error: 'struct v4l2_subdev' has no member named 'entity' linux-2.6/drivers/media/video/mt9m032.c: In function 'mt9m032_remove': linux-2.6/drivers/media/video/mt9m032.c:842: error: 'struct v4l2_subdev' has no member named 'entity' make[4]: *** [drivers/media/video/mt9m032.o] Error 1 by adding a dependency on VIDEO_V4L2_SUBDEV_API. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sylwester Nawrocki authored
Signed-off-by:
Sylwester Nawrocki <sylvester.nawrocki@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
Fix a copy-paste typo and a nested locking function call in mt9m032. Signed-off-by:
-
- 18 Apr, 2012 3 commits
-
-
David Härdeman authored
Setting the correct mode is required by rc-core or scancodes won't be generated (which isn't very user-friendly). This one-line fix should be suitable for 3.4-rc2. Signed-off-by:
David Härdeman <david@hardeman.nu> Cc: stable@kernel.org Signed-off-by:
-
Alexey Khoroshilov authored
If sanity check fails in scu_command(), goto error leads to unlock of an unheld mutex. The check should not fail in reality, but it nevertheless worth fixing. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: stable@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
There are some softwares (Kaffeine and likely xine) that uses a DVBv5 call to switch to DVB-S2, but expects that a DVBv3 call to switch back to DVB-S. Well, this is not right, as a DVBv3 call doesn't know anything about delivery systems. However, as, by accident, this used to work, we need to restore its behavior, in order to avoid regressions with those softwares. Reported on this Fedora 16 bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=812895Reported-by:
Dieter Roever <Dieter.Roever@gmx.de> Cc: stable@kernel.org # for version 3.3 Signed-off-by:
-
- 09 Apr, 2012 6 commits
-
-
Laurent Pinchart authored
The driver frees the clock samples buffer before stopping the video buffers queue. If a DQBUF call arrives in-between, uvc_video_clock_update() will be called with a NULL clock samples buffer, leading to a crash. This occurs very frequently when using the webcam with the flash browser plugin. Move clock initialization/cleanup to uvc_video_enable() in order to free the clock samples buffer after the queue is stopped. Make sure the clock is reset at resume time to avoid miscalculating timestamps. Signed-off-by:
-
Hans Verkuil authored
On Sunday, April 01, 2012 21:09:34 Tracey Dent wrote: > radio-maxiradio depends on SND_FM801_TEA575X_BOOL to build or will > result in an build error such as: > > Kernel: arch/x86/boot/bzImage is ready (#1) > ERROR: "snd_tea575x_init" [drivers/media/radio/radio-maxiradio.ko] undefined! > ERROR: "snd_tea575x_exit" [drivers/media/radio/radio-maxiradio.ko] undefined! > WARNING: modpost: Found 6 section mismatch(es). > To see full details build your kernel with: > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > > Select CONFIG_SND_TEA575X to fixes problem and enable > the driver to be built as desired. > > v2: > instead of selecting CONFIG_SND_FM801_TEA575X_BOOL, select > CONFIG_SND_TEA575X, which in turns selects CONFIG_SND_FM801_TEA575X_BOOL > and any other dependencies for it to build. No, this is the correct patch: RADIO_MAXIRADIO should be treated just like RADIO_SF16FMR2, I just didn't realize at the time that it had to be added as a SND_TEA575X dependency. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
Shea Levy <shea@shealevy.com> Acked-by:
Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
Hans Petter Selasky authored
has_get_frontend() should return a boolean, not a pointer. Signed-off-by:
Hans Petter Selasky <hselasky@c2i.net> Signed-off-by:
-
Malcolm Priestley authored
On some systems the device does not respond or give obscure values after cold, warm or firmware reboot. This patch retries to get chip version and type 5 times. If it fails it applies chip version 0x1 and type 0x9135. This patch does not fix warm cycle problems from other operating systems and indeed the reverse applies. Users should power off cold boot. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Hans Verkuil authored
When I converted ivtv to the new decoder API I introduced a regression in the support of the old channel select API. Thanks to Martin Dauskardt for reporting this. Signed-off-by:
Andy Walls <awalls@md.metrocast.net> Signed-off-by:
-
Chris Rankin authored
The commit e399ce77 has broken the DVB ABI for xine: The problem is that xine is expecting every event after a successful FE_SET_FRONTEND ioctl to have a non-zero frequency parameter, regardless of whether the tuning process has LOCKed yet. What used to happen is that the events inherited the initial tuning parameters from the FE_SET_FRONTEND call. However, the fepriv->parameters_out struct is now not initialised until the status contains the FE_HAS_LOCK bit. You might argue that this behaviour is intentional, except that if an application other than xine uses the DVB adapter and manages to set the parameters_out.frequency field to something other than zero, then xine no longer has any problems until either the adapter is replugged or the kernel modules reloaded. This can only mean that the fepriv->parameters_out struct still contains the (stale) tuning information from the previous application. Signed-off-by:
Chris Rankin <rankincj@yahoo.com> Cc: stable@kernel.org # for kernel version 3.3 Signed-off-by:
-
- 23 Mar, 2012 1 commit
-
-
Mauro Carvalho Chehab authored
* staging/for_v3.4: (10117 commits) [media] update CARDLIST.em28xx [media] partially reverts changeset fa5527cd [media] stb0899: fix the limits for signal strength values [media] em28xx: support for 2304:0242 PCTV QuatroStick (510e) [media] em28xx: support for 2013:0251 PCTV QuatroStick nano (520e) [media] -EINVAL -> -ENOTTY [media] gspca - sn9c20x: Cleanup source [media] gspca - sn9c20x: Simplify register write for capture start/stop [media] gspca - sn9c20x: Add automatic JPEG compression mechanism [media] gspca - sn9c20x: Greater delay in case of sensor no response [media] gspca - sn9c20x: Optimize the code of write sequences [media] gspca - sn9c20x: Add the JPEG compression quality control [media] gspca - sn9c20x: Add a delay after Omnivision sensor reset [media] gspca - sn9c20x: Propagate USB errors to higher level [media] gspca - sn9c20x: Use the new video control mechanism [media] gspca - sn9c20x: Fix loss of frame start [media] gspca - zc3xx: Lack of register 08 value for sensor cs2102k [media] gspca - ov534_9: Add brightness to OmniVision 5621 sensor [media] gspca - zc3xx: Add V4L2_CID_JPEG_COMPRESSION_QUALITY control support [media] pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5 ...
-
- 20 Mar, 2012 26 commits
-
-
Mauro Carvalho Chehab authored
Add the new DRX-K based devices there. Signed-off-by: -
Mauro Carvalho Chehab authored
This patch is applying some hunks that are already at changeset c247d7b1, causing a compilation breakage. Signed-off-by:
-
Klaus Schmidinger authored
stb0899: fix the limits for signal strength values stb0899_read_signal_strength() adds an offset to the result of the table lookup. That offset must correspond to the lowest value in the lookup table, to make sure the result doesn't get below 0, which would mean a "very high" value since the parameter is unsigned. 'strength' and 'snr' need to be initialized to 0 to make sure they have a defined result in case there is no "internal->lock". Signed-off-by:
Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> Cc: Manu Abraham <abraham.manu@gmail.com> Signed-off-by:
-
Ivan Kalvachev authored
It is mostly copy/paste of the 520e code with setting GPIO7 removed (no LED light). I've worked on just released vanilla linux-3.3.0 kernel, so there may be 1/2 lines offset to the internal working source, but most of the code should apply cleanly. I was able to get the DVB-C working (tuned and watched TV). Haven't tested DVB-T (no signal atm). Special thanks to everybody who worked on the code and to Antti Palosaari and Devin Heitmueller who provided essential support on irc. Hardware is based of: Empia EM2884 Micronas DRX 3926K NXP TDA18271HDC2 AVF4910 (not used atm) Signed-off-by:
Ivan Kalvachev <ikalvachev@gmail.com> Signed-off-by:
-
Antti Palosaari authored
Hardware is based of: Empia EM2884 Micronas DRX 3926K NXP TDA18271HDC2 ... + analog parts. Analog is not supported currently. Only DVB-T and DVB-C. There seems to be still problems for locking DVB-C channels which have strong signal. Attenuator helps. I think it is demodulator IF/RF AGC issue. Lets fix it later. Patches are welcome. Signed-off-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Hans Verkuil authored
I found one more place where -EINVAL is used instead of -ENOTTY: Note that drivers/media/dvb/dvb-core/dvbdev.c has the same code, but as far as I can tell DVB is still using -EINVAL for unknown ioctls so I didn't change that. Signed-off-by:
-
Jean-François Moine authored
- copyright change - use the kbuild module name for messages - remove useless code - add/remove blank lines, parenthesis, braces - add/change some information messages Signed-off-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
Jean-François Moine authored
The bridge register 1061 may take only the values 01 (stop) or 03 (start). Signed-off-by:
-
Jean-François Moine authored
The JPEG compression may be adjusted from the packet fill ratio and from the flag 'USB FIFO full' returned in each frame. The code is adapted from the one in gspca sonixj and uses a workqueue. Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
The new functions i2c_w1_buf() and i2c_w2_buf() handle the write loops. Signed-off-by:
-
Jean-François Moine authored
The JPEG compression quality was hardcoded to 95%. This value was too big, raising often buffer overflows. This quality is now 80% by default and is settable. Signed-off-by:
-
Jean-François Moine authored
The reset of the Omnivision sensors takes a long time (200ms). Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
Signed-off-by:
-
Jean-François Moine authored
The frame header was checked on packets of size 64 bytes only, while the webcams may put a frame header at the beginning of bigger packets. Signed-off-by:
-
Jean-François Moine authored
The line defining the value of the register 08 for the sensor cs2102k was commented by error in commit 30c73d46. Signed-off-by:
-
Jose Alberto Reguero authored
This patch adds brightness control to the OmniVision 5621 sensor. Signed-off-by:
-
Jean-François Moine authored
This patch is adapted from Sylwester's patch proposed on 2012/02/22. The JPEG compression control does not work with the autoquality done for the sensors hv7131r and pas202b. Acked-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Michael Krufky authored
The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner instead of a tda18271c1 tuner as used in revision D1E9. To account for this, we must hardcode the frontend configuration to use the same IF frequency configuration for both revisions of the device. 6MHz DVB-T is unaffected by this issue, as the recommended IF Frequency configuration for 6MHz DVB-T is the same on both c1 and c2 revisions of the tda18271 tuner. Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Cc: Mike Isely <isely@pobox.com> Cc: stable@kernel.org Signed-off-by:
-
Michael Krufky authored
Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl() This code breaks driver operation in kernel 3.3 and later, although it works properly in 3.2 Disable register access to 0x12 for now. Signed-off-by:
-
Antti Palosaari authored
Hardware is based of: Empia EM2874B Micronas DRX 3913KA2 NXP TDA18271HDC2 Only DVB-C supported currently since missing firmware. According to my tests, DRX 3913KA2 demodulator requires firmware in order to support DVB-T mode. Signed-off-by:
-
Jonathan Corbet authored
We've spammed enough logfiles at this point. Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Jonathan Corbet authored
We still need to power up the controller to avoid unsightly self-immolation should something try to access its registers, but the sensor can stay powered down unless the camera was actually operating at suspend time. This gets rid of the camera LED flash on resume, fixing OLPC bug #11644. Signed-off-by:
-
Jonathan Corbet authored
There is only one frame known to the DMA engine in scatter/gather mode, but it still tells us that any or all of frames 1-3 are done at each completion interrupt. Avoid the creation of junk frames by being sure to only "complete" one on each interrupt. Signed-off-by:
-
Jonathan Corbet authored
I had learned through hard experience that dinking around with the DMA descriptors while the C1_DESC_ENA enable bit was set is a recipe for all kinds of truly malicious behavior on the hardware's part, regardless of whether the DMA engine is actually operating at the time. That notwithstanding, the driver did so dink, resulting in "green frame" captures and the death of the system in random, spectacular ways. Move the tweaking of C1_DESC_ENA to the same function that sets the descriptor so we know that we'll never try to set a descriptor while that bit is set. Signed-off-by:
-
