- 08 Nov, 2013 9 commits
-
-
Mauro Carvalho Chehab authored
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 authored
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 authored
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 authored
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:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Mauro Carvalho Chehab authored
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 authored
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 authored
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:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Mauro Carvalho Chehab authored
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 authored
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:
-
- 07 Nov, 2013 6 commits
-
-
Sean Young authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
- 31 Oct, 2013 25 commits
-
-
Srinivas Kandagatla authored
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:
-
Sachin Kamat authored
'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:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Sachin Kamat authored
'of_match_ptr' is defined in linux/of.h. Include it explicitly to avoid build breakage in the future. Signed-off-by:
-
Laurent Pinchart authored
The helper function is defined by a macro that is erroneously called with the compose rectangle instead of the crop rectangle. Fix it. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
Daniel Jeong authored
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:
-
Antti Palosaari authored
Components are RTL2832P + R828D + MN88472. Currently support only DVB-T as there is no driver for MN88472 demod. Signed-off-by:
-
Antti Palosaari authored
RTL2832P is version of RTL2832U with extra TS interface. As for now, we support only integrated RTL2832 demod. Signed-off-by:
-
Antti Palosaari authored
Use R820T config for R828D too as those are about same tuner. Signed-off-by:
-
Antti Palosaari authored
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:
-
Russell King - ARM Linux authored
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:
-
Jean-Francois Thibert authored
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:
-
Randy Dunlap authored
Fix build error when VIDEOBUF2_CORE=m and USB_MSI3101=y. drivers/built-in.o: In function `msi3101_buf_queue': sdr-msi3101.c:(.text+0x1298d6): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_cleanup_queued_bufs': sdr-msi3101.c:(.text+0x1299c7): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_isoc_handler': sdr-msi3101.c:(.text+0x12a08d): undefined reference to `vb2_plane_vaddr' sdr-msi3101.c:(.text+0x12a0b9): undefined reference to `vb2_buffer_done' drivers/built-in.o: In function `msi3101_probe': sdr-msi3101.c:(.text+0x12a1c5): undefined reference to `vb2_vmalloc_memops' sdr-msi3101.c:(.text+0x12a1d7): undefined reference to `vb2_queue_init' drivers/built-in.o:(.rodata+0x34cf0): undefined reference to `vb2_ioctl_reqbufs' drivers/built-in.o:(.rodata+0x34cf4): undefined reference to `vb2_ioctl_querybuf' drivers/built-in.o:(.rodata+0x34cf8): undefined reference to `vb2_ioctl_qbuf' drivers/built-in.o:(.rodata+0x34d00): undefined reference to `vb2_ioctl_dqbuf' drivers/built-in.o:(.rodata+0x34d04): undefined reference to `vb2_ioctl_create_bufs' drivers/built-in.o:(.rodata+0x34d08): undefined reference to `vb2_ioctl_prepare_buf' drivers/built-in.o:(.rodata+0x34d18): undefined reference to `vb2_ioctl_streamon' drivers/built-in.o:(.rodata+0x34d1c): undefined reference to `vb2_ioctl_streamoff' drivers/built-in.o:(.rodata+0x35580): undefined reference to `vb2_fop_read' drivers/built-in.o:(.rodata+0x35588): undefined reference to `vb2_fop_poll' drivers/built-in.o:(.rodata+0x35598): undefined reference to `vb2_fop_mmap' drivers/built-in.o:(.rodata+0x355a0): undefined reference to `vb2_fop_release' drivers/built-in.o:(.data+0x23b40): undefined reference to `vb2_ops_wait_prepare' drivers/built-in.o:(.data+0x23b44): undefined reference to `vb2_ops_wait_finish' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Jingoo Han authored
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:
-
Jingoo Han authored
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:
-
Alexandru Juncu authored
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:
-
Michael Opdenacker authored
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:
-
Valentine Barshak authored
Signed-off-by:
Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by:
-
Guennadi Liakhovetski authored
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 authored
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 authored
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 authored
To obtain a clock reference consumers supply their device object to the V4L2 clock framework. The latter then uses the consumer device name to find a matching clock. For that to work V4L2 clock providers have to provide the same device name, when registering clocks. This patch adds a helper macro to generate a suitable device name for I2C devices. Signed-off-by:
-
Guennadi Liakhovetski authored
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:
-
