aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media
AgeCommit message (Collapse)Author
2013-11-08[media] cxusb: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/usb/dvb-usb/cxusb.c:209:1: warning: 'cxusb_i2c_xfer' uses dynamic stack allocation [enabled by default] drivers/media/usb/dvb-usb/cxusb.c:69:1: warning: 'cxusb_ctrl_msg' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer to be the max size of a control URB payload data (64 bytes). Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] v4l2-async: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS, with is currently 128. That means that the buffer size can be up to 128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack. Worse than that, someone could increase it and cause real troubles. So, let's use dynamically allocated data, instead. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] cimax2: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/pci/cx23885/cimax2.c:149:1: warning: 'netup_write_i2c' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] tuner-xc2028: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this driver, the maximum limit is 80, used only on tm6000 driver. This limit is due to the size of the USB control URBs. Ok, it would be theoretically possible to use a bigger size on PCI devices, but the firmware load time is already good enough. Anyway, if some usage requires more, it is just a matter of also increasing the buffer size at load_firmware(). Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] tuners: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default] drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] av7110_hw: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/pci/ttpci/av7110_hw.c:510:1: warning: 'av7110_fw_cmd' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this driver, the maximum fw command size is 6 + 2, as checked using: $ git grep -A1 av7110_fw_cmd drivers/media/pci/ttpci/ So, use 8 for the buffer size. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] stv090x: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] stv0367: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] stb0899_drv: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] dvb-frontends: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Reviewed-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] dvb-frontends: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default] drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. Considering that I2C transfers are generally limited, and that devices used on USB has a max data length of 64 bytes for the control URBs. So, it seem safe to use 64 bytes as the hard limit for all those devices. On most cases, the limit is a way lower than that, but this limit is small enough to not affect the Kernel stack, and it is a no brain limit, as using smaller ones would require to either carefully each driver or to take a look on each datasheet. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] s5h1420: Don't use dynamic static allocationMauro Carvalho Chehab
Dynamic static allocation is evil, as Kernel stack is too low, and compilation complains about it on some archs: drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default] Instead, let's enforce a limit for the buffer. In the specific case of this frontend, only ttpci uses it. The maximum number of messages there is two, on I2C read operations. As the logic can add an extra operation, change the size to 3. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] uvc/lirc_serial: Fix some warnings on parisc archMauro Carvalho Chehab
On this arch, usec is not unsigned long. So, we need to typecast, in order to remove those warnings: drivers/media/usb/uvc/uvc_video.c: In function 'uvc_video_clock_update': drivers/media/usb/uvc/uvc_video.c:678:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 9 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c: In function 'irq_handler': drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:707:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:719:5: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type '__kernel_suseconds_t' [-Wformat] drivers/staging/media/lirc/lirc_serial.c:728:6: warning: format '%lx' expects argument of type 'long unsigned int', but argument 7 has type '__kernel_suseconds_t' [-Wformat] Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] rc: Fir warnings on m68k archMauro Carvalho Chehab
Fix the following warnings: drivers/media/rc/fintek-cir.c: In function 'fintek_cr_write': drivers/media/rc/fintek-cir.c:45:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c:46:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c: In function 'fintek_cr_read': drivers/media/rc/fintek-cir.c:54:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c:55:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_enable': drivers/media/rc/fintek-cir.c:80:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c:81:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/fintek-cir.c: In function 'fintek_config_mode_disable': drivers/media/rc/fintek-cir.c:87:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_write': drivers/media/rc/nuvoton-cir.c:45:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c:46:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c: In function 'nvt_cr_read': drivers/media/rc/nuvoton-cir.c:52:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c:53:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_enable': drivers/media/rc/nuvoton-cir.c:74:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c:75:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c: In function 'nvt_efm_disable': drivers/media/rc/nuvoton-cir.c:81:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c: In function 'nvt_select_logical_dev': drivers/media/rc/nuvoton-cir.c:91:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] drivers/media/rc/nuvoton-cir.c:92:2: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Those are caused because the I/O port is u32, instead of u8. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-08[media] radio-si470x-i2c: fix a warning on ia64Mauro Carvalho Chehab
on ia64, those warnings appear: drivers/media/radio/si470x/radio-si470x-i2c.c:470:12: warning: 'si470x_i2c_suspend' defined but not used [-Wunused-function] drivers/media/radio/si470x/radio-si470x-i2c.c:487:12: warning: 'si470x_i2c_resume' defined but not used [-Wunused-function] They're caused because the PM logic uses this define: #define SET_SYSTEM_SLEEP_PM_OPS() With is only defined for CONFIG_PM_SLEEP. So, change the logic there to test for CONFIG_PM_SLEEP, instead of CONFIG_PM. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] iguanair: simplify calculation of carrier delay cyclesSean Young
Simplify the logic that calculates the carrier, and removes a warning on avr32 arch: drivers/media/rc/iguanair.c: In function 'iguanair_set_tx_carrier': drivers/media/rc/iguanair.c:304: warning: 'sevens' may be used uninitialized in this function Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] tef6862: fix warning on avr32 archMauro Carvalho Chehab
On avr32 arch, we get those warnings: drivers/media/radio/tef6862.c:59:1: warning: "MODE_SHIFT" redefined In file included from /devel/v4l/ktest-build/arch/avr32/include/asm/ptrace.h:11, arch/avr32/include/uapi/asm/ptrace.h:41:1: warning: this is the location of the previous definition Prefix MSA_ to the MSA register bitmap macros, to avoid reusing the same symbol. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] cx18: struct i2c_client is too big for stackMauro Carvalho Chehab
drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom': drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=] That happens because the routine allocates 256 bytes for an eeprom buffer, plus the size of struct i2c_client, with is big. Change the logic to dynamically allocate/deallocate space for struct i2c_client, instead of using the stack. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] zoran: don't build it on alphaMauro Carvalho Chehab
This driver uses virt_to_bus() with is deprecated on Alpha: drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_vfe': drivers/media/pci/zoran/zoran_device.c:451:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_device.c:453:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_device.c: In function 'zr36057_set_jpg': drivers/media/pci/zoran/zoran_device.c:796:2: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c: In function 'v4l_fbuffer_alloc': drivers/media/pci/zoran/zoran_driver.c:241:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:245:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c: In function 'jpg_fbuffer_alloc': drivers/media/pci/zoran/zoran_driver.c:334:3: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:347:5: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] drivers/media/pci/zoran/zoran_driver.c:366:6: warning: 'virt_to_bus' is deprecated (declared at /devel/v4l/ktest-build/arch/alpha/include/asm/io.h:114) [-Wdeprecated-declarations] As we're not even sure if it works on Alpha, better to just disable its compilation there. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] radio-shark: remove a warning when CONFIG_PM is not definedMauro Carvalho Chehab
On alpha, allyesconfig doesn't have CONFIG_PM, and produces the following warnings: drivers/media/radio/radio-shark.c:274:13: warning: 'shark_resume_leds' defined but not used [-Wunused-function] drivers/media/radio/radio-shark2.c:240:13: warning: 'shark_resume_leds' defined but not used [-Wunused-function] That's because those functions are used only at device resume. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07[media] tda9887: remove an warning when compiling for alphaMauro Carvalho Chehab
There's no need to zero the buffer, as if the routine gets an error, rc will be different than one. That fixes the following warning: drivers/media/tuners/tda9887.c: In function 'tda9887_status': drivers/media/tuners/tda9887.c:539:2: warning: value computed is not used [-Wunused-value] While here, make fix the CodingStyle on this function. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-11-07Merge tag 'usb-3.13-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB driver update from Greg KH: "Here's the big USB driver update for 3.13-rc1. It includes the usual xhci changes, EHCI updates to get the scheduling of USB transactions working better, and a raft of gadget and musb updates as well. All of this has been in linux-next for a while with no reported issues" * tag 'usb-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (305 commits) USB: Maintainers change for usb serial drivers usb: usbtest: support container id descriptor test usb: usbtest: support superspeed device capbility descriptor test usb: usbtest: support usb2 extension descriptor test usb: chipidea: only get vbus regulator for non-peripheral mode USB: ehci-atmel: add usb_clk for transition to CCF usb: cdc-wdm: ignore speed change notifications USB: cdc-wdm: support back-to-back USB_CDC_NOTIFY_RESPONSE_AVAILABLE notifications usbatm: Fix dynamic_debug / ratelimited atm_dbg and atm_rldbg macros printk: pr_debug_ratelimited: check state first to reduce "callbacks suppressed" messages usb: usbtest: support bos descriptor test for usb 3.0 USB: phy: samsung: Support multiple PHYs of same type usb: wusbcore: change WA_SEGS_MAX to a legal value usb: wusbcore: add a quirk for Alereon HWA device isoc behavior usb: wusbcore: combine multiple isoc frames in a single transfer request. usb: wusbcore: set the RPIPE wMaxPacketSize value correctly usb: chipidea: host: more enhancement when ci->hcd is NULL usb: ohci: remove ep93xx bus glue platform driver usb: usbtest: fix checkpatch warning as sizeof code style UWB: clean up attribute use by using ATTRIBUTE_GROUPS() ...
2013-10-31DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()Russell King
The code sequence: isp->raw_dmamask = DMA_BIT_MASK(32); isp->dev->dma_mask = &isp->raw_dmamask; isp->dev->coherent_dma_mask = DMA_BIT_MASK(32); bypasses the architectures check on the DMA mask. It can be replaced with dma_coerce_mask_and_coherent(), avoiding the direct initialization of this mask. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-10-31[media] media: st-rc: Add ST remote control driverSrinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF receiver and transmitter. This IP (IRB) is common across all the ST parts for settop box platforms. IRB is embedded in ST COMMS IP block. It supports both Rx & Tx functionality. This driver adds only Rx functionality via LIRC codec. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] gpio-ir-recv: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] tvp7002: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] tvp514x: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] ths8200: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] adv7343: Include linux/of.h headerSachin Kamat
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] media: i2c: add driver for dual LED Flash, lm3560Daniel Jeong
Adds the driver for the LM3560, dual LED Flash The LM3560 has two 1A constant current driver for high current white LEDs. It is controlled via an I2C compatible interface(up to 400kHz). Each flash brightness, torch brightness and enable/disable can be controlled independantly, but flash timeout and operation mode are shared. Signed-off-by: Daniel Jeong <gshark.jeong@gmail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] rtl28xxu: add 15f4:0131 Astrometa DVB-T2Antti Palosaari
Components are RTL2832P + R828D + MN88472. Currently support only DVB-T as there is no driver for MN88472 demod. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] rtl28xxu: add RTL2832P + R828D supportAntti Palosaari
RTL2832P is version of RTL2832U with extra TS interface. As for now, we support only integrated RTL2832 demod. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] rtl2832: add new tuner R828DAntti Palosaari
Use R820T config for R828D too as those are about same tuner. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] r820t: add support for R828DAntti Palosaari
Small changes in order to support tuner version R828D @ 16 MHz clock. There was 'vco_fine_tune' check, which seems to adjust synthesizer output divider (mixer dix / LO div / Rout) by one. R828D seems to return vco_fine_tune=1 every time and that condition causes tuning fail as output divider was increased by one. Resolve problem by skipping whole condition in case of R828D tuner. Just to mention, other tuner, R820T, seems to return 2 here. Synthesizer maximum frequency check was hard coded to check synthesizer N and thus worked correctly only for clock frequencies around 30 MHz. As whole test is quite useless in any case, I removed it totally. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] media/i2c: ths8200: fix build failure with gcc 4.5.4Russell King - ARM Linux
v3.12-rc fails to build with this error: drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in initializer drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union initializer drivers/media/i2c/ths8200.c:50:3: error: (near initialization for 'ths8200_timings_cap.reserved') drivers/media/i2c/ths8200.c:51:3: error: field name not in record or union initializer drivers/media/i2c/ths8200.c:51:3: error: (near initialization for 'ths8200_timings_cap.reserved') ... with gcc 4.5.4. This error was not detected in builds prior to v3.12-rc. This patch fixes this. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org # For kernel v3.12 Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] Add support for KWorld UB435-Q V2Jean-Francois Thibert
This patch adds support for the UB435-Q V2. You might need to use the device once with the Windows driver provided by KWorld in order to permanently reprogram the device descriptors. Thanks to Jarod Wilson for the initial attempt at adding support for this device. [m.chehab@samsung.com: Fixed Whitespace mangling, Coding Style and improved the error handling at DVB attach] Signed-off-by: Jean-Francois Thibert <jfthibert@google.com> Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] ddbridge: Remove casting the return value which is a void pointerJingoo Han
Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] ngene: Remove casting the return value which is a void pointerJingoo Han
Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] dm1105: remove unneeded not-null testAlexandru Juncu
i2c_adap is a field of a struct and will always be allocated so its address will never be null. Suggested by coccinelle, manually verified. Signed-off-by: Alexandru Juncu <alexj@rosedu.org> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] sh_mobile_ceu_camera: remove deprecated IRQF_DISABLEDMichael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] media: rcar_vin: Add preliminary r8a7790 supportValentine Barshak
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] V4L2: em28xx: tell the ov2640 driver to balance clock enabling ↵Guennadi Liakhovetski
internally The em28xx driver only calls subdevices' .s_power() method to power them down, relying on the hardware to wake up automatically, which is usually the case with tuners. This was acceptable with the old .standby() method, but is wrong with .s_power(). Fixing the driver would be difficult due to a broad supported hardware base. Instead this patch makes use of the unbalanced_power soc-camera subdevice flag to tell the ov2640 driver to balance calls to v4l2_clk_enable() and v4l2_clk_disable() internally. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] V4L2: soc-camera: work around unbalanced calls to .s_power()Guennadi Liakhovetski
Some non soc-camera drivers, e.g. em28xx, use subdevice drivers, originally written for soc-camera, which use soc_camera_power_on() and soc_camera_power_off() helpers to implement their .s_power() methods. Those helpers in turn can enable and disable a clock, if it is supplied to them as a parameter. This works well when camera host drivers balance their calls to subdevices' .s_power() methods. However, some such drivers fail to do that, which leads to unbalanced calls to v4l2_clk_enable() / v4l2_clk_disable(), which then in turn produce kernel warnings. Such behaviour is wrong and should be fixed, however, sometimes it is difficult, because some of those drivers are rather old and use lots of subdevices, which all should be tested after such a fix. To support such drivers this patch adds a work-around, allowing host drivers or platforms to set a flag, in which case soc-camera helpers will only enable the clock, if it is disabled, and disable it only once on the first call to .s_power(0). Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] V4L2: em28xx: register a V4L2 clock sourceGuennadi Liakhovetski
Camera sensors usually require a master clock for data sampling. This patch registers such a clock source for em28xx cameras. This fixes the currently broken em28xx ov2640 camera support and can also be used by other camera sensors. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] V4L2: add v4l2-clock helpers to register and unregister a fixed-rate ↵Guennadi Liakhovetski
clock Many bridges and video host controllers supply fixed rate always on clocks to their I2C devices. This patch adds two simple helpers to register and unregister such a clock. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] soc-camera: switch to using the new struct v4l2_subdev_platform_dataGuennadi Liakhovetski
This prepares soc-camera to use struct v4l2_subdev_platform_data for its subdevice-facing API, which would allow subdevice driver re-use. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-31[media] imx074: fix error handling for failed async subdevice registrationGuennadi Liakhovetski
If v4l2_async_register_subdev() fails, don't skip the clean up. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-28[media] s5p-mfc: remove deprecated IRQF_DISABLEDMichael Opdenacker
This patch proposes to remove the use of the IRQF_DISABLED flag It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-28[media] s5p-mfc: call wake_up_dev if in suspend modePrathyush K
If a frame is still decoding when system enters suspend mode, we wait on the device queue for a interrupt condition. This sometimes leads to a timeout because the device queue might not be woken up everytime. Usually, the context queue gets woken up when that context's frame gets decoded. This patch adds a condition to wake up the device queue along with the context queue when the system is in suspend mode. Since the device queue is now woken up, we don't have to check the context's int_cond flag while waiting. Also, we can skip calling try_run after waking up the device queue to ensure that we don't have to wait for more than one frame to be processed. Signed-off-by: Prathyush K <prathyush.k@samsung.com> Signed-off-by: Arun Mankuzhi <arun.m@samsung.com> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
2013-10-28[media] s5p-mfc: Adjust the default values of some encoder paramsArun Kumar K
The patch sets the default values of MAX_QP and GOP size encoder parameters to some firmware recommended default values. This enables the applications to get a better encoded output using the default settings itself. Signed-off-by: Kiran AVND <avnd.kiran@samsung.com> Signed-off-by: Arun Kumar K <arun.kk@samsung.com> Signed-off-by: Kamil Debski <k.debski@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>