- 17 Dec, 2014 8 commits
-
-
Hans Verkuil authored
The start_streaming op is responsible for starting the video dma, so it shouldn't be called anymore from the buf_queue op. Unfortunately, this call to start_video_dma() was added to the start_streaming op, but was forgotten to be removed from the buf_queue op, which is where it used to be before the vb2 conversion. Calling this function twice causes very hard to find errors: sometimes it works, sometimes it doesn't. It took me a whole friggin' day to track this down, and in the end it was just luck that my eye suddenly triggered on that line. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Hans Verkuil authored
The cx88 vb2 conversion and the vb2 dma_sg improvements were developed separately and were merged separately. Unfortunately, the patch updating drivers to the dma_sg improvements didn't take the updated cx88 driver into account. Basically two ships passing in the night, unaware of one another even though both ships have the same owner, i.e. me :-) Signed-off-by:
Chris Lee <updatelee@gmail.com> Signed-off-by:
-
Hans Verkuil authored
This is easy to forget to do in drivers. While v4l2-compliance will check for it, not everyone remembers to run it. So warn about it. Signed-off-by:
-
Hans Verkuil authored
An error was returned if composing was not supported, instead of if cropping was not supported. A classic copy-and-paste bug. Found with v4l2-compliance. Signed-off-by:
-
Hans Verkuil authored
Update the version to 3.19. Signed-off-by:
-
Hans Verkuil authored
Document the new 'Y'CbCr Encoding' and 'Quantization' controls. Signed-off-by:
-
Hans Verkuil authored
I forgot to add these fields to the relevant structs. Signed-off-by:
-
Hans Verkuil authored
The ycbcr_enc and quantization fields do not need a __u32. Switch to two __u16 types, thus preserving alignment and avoiding holes in the struct. This makes one more __u32 available for future expansion. Suggested by Sakari Ailus. Signed-off-by:
-
- 12 Dec, 2014 5 commits
-
-
Koji Matsuoka authored
The progressive input is captured by the field interrupt. Therefore the end of frame interrupt is unnecessary. Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Koji Matsuoka authored
By applying this patch, it sets to VSYNC field toggle mode not only at the time of progressive mode but at the time of an interlace mode. Signed-off-by:
-
Koji Matsuoka authored
Signed-off-by:
-
Yoshihiro Kaneko authored
Based on platform device work by Matsuoka-san. Signed-off-by:
-
Koji Matsuoka authored
Signed-off-by:
-
- 04 Dec, 2014 27 commits
-
-
Markus Elfring authored
The release_firmware() function was called by the mn88473_init() function even if a previous function call "request_firmware" failed. This implementation detail could be improved by the introduction of another jump label. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The vfree() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
James Hogan authored
Add myself as the maintainer for the Imagination Technologies Infrared Decoder driver. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
James Hogan authored
Don't bother setting .owner = THIS_MODULE, since it's already handled by the platform_driver_register macro. Signed-off-by:
-
James Hogan authored
The ImgTec Infrared decoder block which img-ir drives is only used in IMGWorks SoCs so far, such as the TZ1090 (Meta based) and the upcoming Pistachio (MIPS based). Therefore make the driver depend on METAG (for TZ1090) or MIPS (for Pistachio) or COMPILE_TEST (so that it is included in x86 allmodconfig builds), to avoid cluttering the Kconfig menu with drivers for hardware that isn't yet available on other platforms. Signed-off-by:
-
James Hogan authored
The img_ir_register_decoder() and img_ir_unregister_decoder() functions were dropped prior to the img-ir driver being applied to simplify the protocol decoder setup. However the declarations of these functions in img-ir-hw.h were still included. Delete them since they're completely unused. Signed-off-by:
-
James Hogan authored
The end timer is used for switching back from repeat code timings when no repeat codes have been received for a certain amount of time. When the protocol is changed, the end timer is deleted synchronously with del_timer_sync(), however this takes place while holding the main spin lock, and the timer handler also needs to acquire the spin lock. This opens the possibility of a deadlock on an SMP system if the protocol is changed just as the repeat timer is expiring. One CPU could end up in img_ir_set_decoder() holding the lock and waiting for the end timer to complete, while the other CPU is stuck in the timer handler spinning on the lock held by the first CPU. Lockdep also spots a possible lock inversion in the same code, since img_ir_set_decoder() acquires the img-ir lock before the timer lock, but the timer handler will try and acquire them the other way around: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.18.0-rc5+ #957 Not tainted --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. --------------------------------------------------------- swapper/0/0 just changed the state of lock: (((&hw->end_timer))){+.-...}, at: [<4006ae5c>] _call_timer_fn+0x0/0xfc but this lock was taken by another, HARDIRQ-safe lock in the past: (&(&priv->lock)->rlock#2){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(((&hw->end_timer))); local_irq_disable(); lock(&(&priv->lock)->rlock#2); lock(((&hw->end_timer))); <Interrupt> lock(&(&priv->lock)->rlock#2); *** DEADLOCK *** This is fixed by releasing the main spin lock while performing the del_timer_sync() call. The timer is prevented from restarting before the lock is reacquired by a new "stopping" flag which img_ir_handle_data() checks before updating the timer. Signed-off-by: -
Dylan Rajaratnam authored
A problem was found on Polaris where if the unit it booted via the power button on the infrared remote then the next button press on the remote would return the key code used to power on the unit. The sequence is: - The polaris powered off but with the powerdown controller (PDC) block still powered. - Press power key on remote, IR block receives the key. - Kernel starts, IR code is in IMG_IR_DATA_x but neither IMG_IR_RXDVAL or IMG_IR_RXDVALD2 are set. - Wait any amount of time. - Press any key. - IMG_IR_RXDVAL or IMG_IR_RXDVALD2 is set but IMG_IR_DATA_x is unchanged since the powerup key data was never read. This is worked around by always reading the IMG_IR_DATA_x in img_ir_set_decoder(), rather than only when the IMG_IR_RXDVAL or IMG_IR_RXDVALD2 bit is set. Signed-off-by:
Dylan Rajaratnam <dylan.rajaratnam@imgtec.com> Signed-off-by:
-
Sean Young authored
This fixes the driver on arm. Reported-by:
Steven Guitton <keltiek@gmail.com> Tested-by:
Sean Young <sean@mess.org> Signed-off-by:
-
Markus Elfring authored
The dvb_unregister_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The release_firmware() function was called in some cases by the si2157_init() function during error handling even if the passed variable contained still a null pointer. This implementation detail could be improved by the introduction of another jump label. Signed-off-by:
-
Markus Elfring authored
The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Felipe Balbi authored
commit 68a3c043 ([media] ARM: OMAP2: RX-51: update si4713 platform data) updated board-rx51-peripherals.c so that si4713 could be easily used on DT boot, but it ended up introducing a build warning whenever si4713 isn't enabled. This patches fixes that warning: arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \ ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable] static struct si4713_platform_data rx51_si4713_platform_data = { Cc: Sebastian Reichel <sre@kernel.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
As pointed by smatch: drivers/media/dvb-frontends/stv090x.c:2787 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13 drivers/media/dvb-frontends/stv090x.c:2789 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13 drivers/media/dvb-frontends/stv090x.c:2791 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13 drivers/media/dvb-frontends/stv090x.c:2793 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13 drivers/media/dvb-frontends/stv090x.c:2795 stv090x_optimize_carloop() error: buffer overflow 'car_loop_apsk_low' 11 <= 13 The situation of a buffer overflow won't happen, in practice, with the current values of car_loop table. Yet, the entire logic that checks for those registration values is too complex. So, better to add an explicit check, just in case someone changes the car_loop tables causing a buffer overflow by mistake. This also helps to remove several smatch warnings, with is good. Signed-off-by: -
Mauro Carvalho Chehab authored
if STV090x_RANGEOK is not returned, then STV090x_OUTOFRANGE is returned. However, that part of the code is never reached, as pointed by smatch: drivers/media/dvb-frontends/stv090x.c:2673 stv090x_get_sig_params() info: ignoring unreachable code. So, remove the two uneeded elses, with makes the code a little bit cleaner. No functional changes, and one less smatch warning. Signed-off-by: -
Mauro Carvalho Chehab authored
While writing changeset fdf1bc9f, I noticed some checkpatch complains about the CodingStyle for function parameters. So, clean them. While here, also removes uneeded "extern" from function prototype. No functional changes. Signed-off-by:
-
Mauro Carvalho Chehab authored
This patch is basically produced while testing a tool that Joe Perches sent upstream sometime ago: https://lkml.org/lkml/2014/7/11/794 I used it with those arguments: $ reformat_with_checkpatch.sh drivers/media/usb/em28xx/em28xx*.[ch] It actually produced 24 patches, with is too much, and showed interesting things: gcc produced different codes on most of the patches, even with just linespace changes. The total code data remained the same on all cases I checked though. Anyway, provided that we fold the resulting patches, this tool seems useful. Signed-off-by:
-
Olli Salonen authored
This patch adds support for new type of firmware versions of Si2168 chip. Old type: n x 8 bytes (all data, first byte seems to be 04 or 05) New type: n x 17 bytes (1 byte indicates len and max 16 bytes data) New version of TechnoTrend CT2-4400 drivers (http://www.tt-downloads.de/bda-treiber_4.3.0.0.zip) contains newer firmware for Si2168-B40 that is in the new format. It can be extracted with the following command: dd if=ttTVStick4400_64.sys ibs=1 skip=323872 count=6919 of=dvb-demod-si2168-b40-01.fw Signed-off-by:
Olli Salonen <olli.salonen@iki.fi> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Olli Salonen authored
A debug printout for firmware version. Signed-off-by:
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Josh Wu authored
SVGA height should be 600 not 680. Reported-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
As reported by smatch: drivers/media/tuners/tda18271-common.c:176 tda18271_read_extended() warn: if statement not indented Signed-off-by: -
Mauro Carvalho Chehab authored
Drivers that use dvb_attach can have just one exported symbol, or they will cause compilation breakages depending on the selected frontends. As Jim reported: drivers/built-in.o: In function `technisat_usb2_set_voltage': technisat-usb2.c:(.text+0x3b4919): undefined reference to `stv090x_set_gpio' make: *** [vmlinux] Error 1 That happens because, on his configuration, the configuration is: CONFIG_DVB_USB=y CONFIG_DVB_STV090x=m Luis proposed ar way to fix, but that would just force the STV090x to be selected, even if one wants to use a device with a different frontend. Instead, let's do the right thing: move set_gpio to the configuration structure and fill it during dvb_attach(). This way, the driver can still call it, and dvb_attach() will load stv090x module only if the device really needs it. Reported by: Jim Davis <jim.epost@gmail.com> Cc: Luis Rodriguez <mcgrof@suse.com> Signed-off-by: -
Nibble Max authored
Signed-off-by:
Nibble Max <nibble.max@gmail.com> Reviewed-by:
-
Nibble Max authored
Remove TechnoTrend CT2-4400 and CT2-4650 devices from cxusb. They are supported by dvb-usb-dvbsky driver in PATCH 3/3. Signed-off-by:
-
Nibble Max authored
DVBSky T330 dvb-t2/t/c usb stick: 1>dvb frontend: SI2157A30(tuner), SI2168B40(demod) 2>usb controller: CY7C68013A Signed-off-by:
-
