- 12 Dec, 2014 3 commits
-
-
Koji Matsuoka authored
Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> [g.liakhovetski@gmx.de: minor stylistic and formatting corrections] Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com>
-
Yoshihiro Kaneko authored
Based on platform device work by Matsuoka-san. Signed-off-by:
-
Koji Matsuoka authored
Signed-off-by:
-
- 04 Dec, 2014 36 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:
-
Mauro Carvalho Chehab authored
Fixes following build warnings: gsc-core.c:350:17: warning: 'low_plane' may be used uninitialized gsc-core.c:371:31: warning: 'high_plane' may be used uninitialized Reported-by:
Prabhakar Lad <prabhakar.csengg@gmail.com> Signed-off-by:
-
Antti Palosaari authored
Recent rtl28xxu patch I made moved demod ADC enable from power control to frontend control (due to slave demod support). Because of that we need call USB interface frontend control too in order to enable ADC. Signed-off-by:
-
Laurent Pinchart authored
The function releases the queue if the file being released is the queue owner. The check reads the queue->owner field without taking the queue lock, creating a race condition with functions that set the queue owner, such as vb2_ioctl_reqbufs() for instance. Fix this by moving the queue->owner check within the mutex protected section. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
-
Laurent Pinchart authored
The vb2_fop_poll() implementation tries to be clever on whether it needs to lock the queue mutex by checking whether polling might start fileio. The test requires reading the q->num_buffer field, which is racy if we don't hold the queue mutex in the first place. Remove the extra cleverness and just lock the mutex. Signed-off-by:
-
Sakari Ailus authored
Add support for selection target V4L2_SEL_TGT_NATIVE_SIZE. It is equivalent of what V4L2_SEL_TGT_CROP_BOUNDS used to be. Support for V4L2_SEL_TGT_CROP_BOUNDS is still supported by the driver as a compatibility interface. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Acked-by:
-
Sakari Ailus authored
The fields were previously uninitialised, leaving the returned values to where the user had set them. This was never the intention. Signed-off-by:
-
Sakari Ailus authored
Add input and output capability flags for setting native size of the device, and document them. Signed-off-by:
-
Sakari Ailus authored
The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a sensor's pixel array. Signed-off-by:
-
Sakari Ailus authored
The sub-device format documentation documented scaling configuration through formats. Instead the compose selection rectangle is elsewhere documented to be used for the purpose. Remove scaling related part of the documentation. Signed-off-by:
-
- 02 Dec, 2014 1 commit
-
-
Hans Verkuil authored
When compiling under COMPILE_TEST on a x86_64 the following warnings appear: drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_uservirt_to_phys': drivers/media/platform/omap/omap_vout.c:209:23: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] return virt_to_phys((void *) virtp); ^ drivers/media/platform/omap/omap_vout.c: In function 'omapvid_setup_overlay': drivers/media/platform/omap/omap_vout.c:420:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=] v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, ^ drivers/media/platform/omap/omap_vout.c: In function 'omap_vout_buffer_prepare': drivers/media/platform/omap/omap_vout.c:794:34: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] vout->queued_buf_addr[vb->i] = (u8 *) ^ In file included from arch/x86/include/asm/dma-mapping.h:44:0, from include/linux/dma-mapping.h:82, from drivers/media/platform/omap/omap_vout.c:40: drivers/media/platform/omap/omap_vout.c:803:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dma_addr = dma_map_single(vout->vid_dev->v4l2_dev.dev, (void *) addr, ^ include/asm-generic/dma-mapping-common.h:174:60: note: in definition of macro 'dma_map_single' #define dma_map_single(d, a, s, r) dma_map_single_attrs(d, a, s, r, NULL) ^ These are fixed by this patch. Signed-off-by:
-
