kernel/git/stable/linux-stable.git/drivers/media/i2c, branch linux-3.16.y

media: ov6650: Fix stored frame format not in sync with hardware

2020-02-11T20:03:13+00:00

commit 3143b459de4cdcce67b36827476c966e93c1cf01 upstream. The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings

media: ov6650: Fix incorrect use of JPEG colorspace

2020-02-11T20:03:13+00:00

commit 12500731895ef09afc5b66b86b76c0884fb9c7bf upstream. Since its initial submission, the driver selects V4L2_COLORSPACE_JPEG for supported formats other than V4L2_MBUS_FMT_SBGGR8_1X8. According to v4l2-compliance test program, V4L2_COLORSPACE_JPEG applies exclusively to V4L2_PIX_FMT_JPEG. Since the sensor does not support JPEG format, fix it to always select V4L2_COLORSPACE_SRGB. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings

media: ov6650: Fix sensor possibly not detected on probe

2019-09-23T20:11:45+00:00

commit 933c1320847f5ed6b61a7d10f0a948aa98ccd7b0 upstream. After removal of clock_start() from before soc_camera_init_i2c() in soc_camera_probe() by commit 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") introduced in v3.11, the ov6650 driver could no longer probe the sensor successfully because its clock was no longer turned on in advance. The issue was initially worked around by adding that missing clock_start() equivalent to OMAP1 camera interface driver - the only user of this sensor - but a propoer fix should be rather implemented in the sensor driver code itself. Fix the issue by inserting a delay between the clock is turned on and the sensor I2C registers are read for the first time. Tested on Amstrad Delta with now out of tree but still locally maintained omap1_camera host driver. Fixes: 9aea470b399d ("[media] soc-camera: switch I2C subdevice drivers to use v4l2-clk") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings

media: v4l2: i2c: ov7670: Fix PLL bypass register values

2019-07-09T21:03:47+00:00

commit 61da76beef1e4f0b6ba7be4f8d0cf0dac7ce1f55 upstream. The following commits: commit f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675") commit 04ee6d92047e ("[media] media: ov7670: add possibility to bypass pll for ov7675") introduced the ability to bypass PLL multiplier and use input clock (xvclk) as pixel clock output frequency for ov7675 sensor. PLL is bypassed using register DBLV[7:6], according to ov7670 and ov7675 sensor manuals. Macros used to set DBLV register seem wrong in the driver, as their values do not match what reported in the datasheet. Fix by changing DBLV_* macros to use bits [7:6] and set bits [3:0] to default 0x0a reserved value (according to datasheets). While at there, remove a write to DBLV register in "ov7675_set_framerate()" that over-writes the previous one to the same register that takes "info->pll_bypass" flag into account instead of setting PLL multiplier to 4x unconditionally. And, while at there, since "info->pll_bypass" is only used in set/get_framerate() functions used by ov7675 only, it is not necessary to check for the device id at probe time to make sure that when using ov7670 "info->pll_bypass" is set to false. Fixes: f6dd927f34d6 ("[media] media: ov7670: calculate framerate properly for ov7675") Signed-off-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

media: tvp5150: fix width alignment during set_selection()

2019-02-11T17:53:20+00:00

commit bd24db04101f45a9c1d874fe21b0c7eab7bcadec upstream. The driver ignored the width alignment which exists due to the UYVY colorspace format. Fix the width alignment and make use of the the provided v4l2 helper function to set the width, height and all alignments in one. Fixes: 963ddc63e20d ("[media] media: tvp5150: Add cropping support") Signed-off-by: Marco Felsch Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

media: smiapp: fix timeout checking in smiapp_read_nvm

2018-11-20T18:04:56+00:00

commit 7a2148dfda8001c983f0effd9afd8a7fa58e99c4 upstream. The current code decrements the timeout counter i and the end of each loop i is incremented, so the check for timeout will always be false and hence the timeout mechanism is just a dead code path. Potentially, if the RD_READY bit is not set, we could end up in an infinite loop. Fix this so the timeout starts from 1000 and decrements to zero, if at the end of the loop i is zero we have a timeout condition. Detected by CoverityScan, CID#1324008 ("Logically dead code") Fixes: ccfc97bdb5ae ("[media] smiapp: Add driver") Signed-off-by: Colin Ian King Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

adv7604: use correct drive strength defines

2018-03-03T15:52:31+00:00

The prefix is ADV7604_, not ADV76XX. Fixes: f31b62e14a ("adv7604: add hdmi driver strength adjustment") Signed-off-by: Hans Verkuil Signed-off-by: Ben Hutchings

ov2640: fix vflip control

2017-08-26T01:14:35+00:00

commit 7f140fc2064bcd23e0490d8210650e2ef21c1c89 upstream. Enabling vflip currently causes wrong colors. It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only changes the vertical readout direction. Because pixels are arranged RGRG... in odd lines and GBGB... in even lines, either a one line shift or even/odd line swap is required, too, but apparently this doesn't happen. I finally figured out that this can be done manually by setting REG04_VREF_EN. Looking at hflip, it turns out that bit REG04_HREF_EN is set there permanetly, but according to my tests has no effect on the pixel readout order. So my conclusion is that the current documentation of sensor register 0x04 is wrong (has changed after preliminary datasheet version 2.2). I'm pretty sure that automatic vertical line shift/switch can be enabled, too, but until anyone finds ot how this works, we have to stick with manual switching. Signed-off-by: Frank Schäfer Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings

adv7604: Initialize drive strength to default when using DT

2017-06-05T20:17:00+00:00

commit da8892d410db224d9a24104529794e6e37e0c100 upstream. The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by: Lars-Peter Clausen Reviewed-by: Laurent Pinchart Tested-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings

s5k4ecgx: select CRC32 helper

2017-03-16T02:26:39+00:00

commit c739c0a7c3c2472d7562b8f802cdce44d2597c8b upstream. A rare randconfig build failure shows up in this driver when the CRC32 helper is not there: drivers/media/built-in.o: In function `s5k4ecgx_s_power': s5k4ecgx.c:(.text+0x9eb4): undefined reference to `crc32_le' This adds the 'select' that all other users of this function have. Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Signed-off-by: Arnd Bergmann Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Ben Hutchings