summaryrefslogtreecommitdiff
path: root/drivers/media/i2c
AgeCommit message (Collapse)AuthorFilesLines
2021-09-18media: TDA1997x: fix tda1997x_query_dv_timings() return valueKrzysztof Hałasa1-2/+3
[ Upstream commit 7dee1030871a48d4f3c5a74227a4b4188463479a ] Correctly propagate the tda1997x_detect_std error value. Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18media: imx258: Limit the max analogue gain to 480Umang Jain1-1/+1
[ Upstream commit f809665ee75fff3f4ea8907f406a66d380aeb184 ] The range for analog gain mentioned in the datasheet is [0, 480]. The real gain formula mentioned in the datasheet is: Gain = 512 / (512 – X) Hence, values larger than 511 clearly makes no sense. The gain register field is also documented to be of 9-bits in the datasheet. Certainly, it is enough to infer that, the kernel driver currently advertises an arbitrary analog gain max. Fix it by rectifying the value as per the data sheet i.e. 480. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18media: imx258: Rectify mismatch of VTS valueLaurent Pinchart1-1/+1
[ Upstream commit 51f93add3669f1b1f540de1cf397815afbd4c756 ] The frame_length_lines (0x0340) registers are hard-coded as follows: - 4208x3118 frame_length_lines = 0x0c50 - 2104x1560 frame_length_lines = 0x0638 - 1048x780 frame_length_lines = 0x034c The driver exposes the V4L2_CID_VBLANK control in read-only mode and sets its value to vts_def - height, where vts_def is a mode-dependent value coming from the supported_modes array. It is set using one of the following macros defined in the driver: #define IMX258_VTS_30FPS 0x0c98 #define IMX258_VTS_30FPS_2K 0x0638 #define IMX258_VTS_30FPS_VGA 0x034c There's a clear mismatch in the value for the full resolution mode i.e. IMX258_VTS_30FPS. Fix it by rectifying the macro with the value set for the frame_length_lines register as stated above. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15media: TDA1997x: enable EDID supportKrzysztof Hałasa1-0/+1
[ Upstream commit ea3e1c36e38810427485f06c2becc1f29e54521d ] Without this patch, the TDA19971 chip's EDID is inactive. EDID never worked with this driver, it was all tested with HDMI signal sources which don't need EDID support. Signed-off-by: Krzysztof Halasa <khalasa@piap.pl> Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-19media: subdev: disallow ioctl for saa6588/davinciArnd Bergmann1-2/+2
commit 0a7790be182d32b9b332a37cb4206e24fe94b728 upstream. The saa6588_ioctl() function expects to get called from other kernel functions with a 'saa6588_command' pointer, but I found nothing stops it from getting called from user space instead, which seems rather dangerous. The same thing happens in the davinci vpbe driver with its VENC_GET_FLD command. As a quick fix, add a separate .command() callback pointer for this driver and change the two callers over to that. This change can easily get backported to stable kernels if necessary, but since there are only two drivers, we may want to eventually replace this with a set of more specialized callbacks in the long run. Fixes: c3fda7f835b0 ("V4L/DVB (10537): saa6588: convert to v4l2_subdev.") Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-14media: tc358743: Fix error return code in tc358743_probe_of()Zhen Lei1-0/+1
[ Upstream commit a6b1e7093f0a099571fc8836ab4a589633f956a8 ] When the CSI bps per lane is not in the valid range, an appropriate error code -EINVAL should be returned. However, we currently do not explicitly assign this error code to 'ret'. As a result, 0 was incorrectly returned. Fixes: 256148246852 ("[media] tc358743: support probe from device tree") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: rc: i2c: Fix an error messageChristophe JAILLET1-2/+2
[ Upstream commit 9c87ae1a0dbeb5794957421157fd266d38a869b4 ] 'ret' is known to be 1 here. In fact 'i' is expected instead. Store the return value of 'i2c_master_recv()' in 'ret' so that the error message print the correct error code. Fixes: acaa34bf06e9 ("media: rc: implement zilog transmitter") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: I2C: change 'RST' to "RSET" to fix multiple build errorsRandy Dunlap5-17/+17
[ Upstream commit 8edcb5049ac29aa3c8acc5ef15dd4036543d747e ] The use of an enum named 'RST' conflicts with a #define macro named 'RST' in arch/mips/include/asm/mach-rc32434/rb.h. The MIPS use of RST was there first (AFAICT), so change the media/i2c/ uses of RST to be named 'RSET'. 'git grep -w RSET' does not report any naming conflicts with the new name. This fixes multiple build errors: arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ drivers/media/i2c/s5c73m3/s5c73m3.h:356:2: note: in expansion of macro 'RST' 356 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k6aa.c:180:2: note: in expansion of macro 'RST' 180 | RST, | ^~~ ../arch/mips/include/asm/mach-rc32434/rb.h:15:14: error: expected identifier before '(' token 15 | #define RST (1 << 15) | ^ ../drivers/media/i2c/s5k5baf.c:238:2: note: in expansion of macro 'RST' 238 | RST, | ^~~ and some others that I have trimmed. Fixes: cac47f1822fc ("[media] V4L: Add S5C73M3 camera driver") Fixes: 8b99312b7214 ("[media] Add v4l2 subdev driver for S5K4ECGX sensor") Fixes: 7d459937dc09 ("[media] Add driver for Samsung S5K5BAF camera sensor") Fixes: bfa8dd3a0524 ("[media] v4l: Add v4l2 subdev driver for S5K6AAFX sensor") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Sangwook Lee <sangwook.lee@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-14media: i2c: ov2659: Use clk_{prepare_enable,disable_unprepare}() to set ↵Dillon Min1-6/+18
xvclk on/off [ Upstream commit 24786ccd9c80fdb05494aa4d90fcb8f34295c193 ] On some platform(imx6q), xvclk might not switch on in advance, also for power save purpose, xvclk should not be always on. so, add clk_prepare_enable(), clk_disable_unprepare() in driver side to set xvclk on/off at proper stage. Add following changes: - add 'struct clk *clk;' in 'struct ov2659 {}' - enable xvclk in ov2659_power_on() - disable xvclk in ov2659_power_off() Signed-off-by: Dillon Min <dillon.minfei@gmail.com> Acked-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14media: i2c: imx219: Balance runtime PM use-countLad Prabhakar1-15/+17
[ Upstream commit dd90caa0111e178b52b21e56364bc2244a3973b3 ] Move incrementing/decrementing runtime PM count to imx219_start_streaming()/imx219_stop_streaming() functions respectively. This fixes an issue of unbalanced runtime PM count in resume callback error path where streaming is stopped and runtime PM count is left unbalanced. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-14media: i2c: imx219: Move out locking/unlocking of vflip and hflip controls ↵Lad Prabhakar1-6/+13
from imx219_set_stream [ Upstream commit 745d4612d2c853c00abadbf69799c8aee7f99c39 ] Move out locking/unlocking of vflip and hflip controls from imx219_set_stream() to the imx219_start_streaming()/ imx219_stop_streaming() respectively. This fixes an issue in resume callback error path where streaming is stopped and the controls are left in locked state. Fixes: 1283b3b8f82b9 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: adv7842: fix possible use-after-free in adv7842_remove()Yang Yingliang1-1/+1
[ Upstream commit 4a15275b6a18597079f18241c87511406575179a ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: tda1997: Fix possible use-after-free in tda1997x_remove()Yang Yingliang1-1/+1
[ Upstream commit 7f820ab5d4eebfe2d970d32a76ae496a6c286f0f ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: i2c: adv7511-v4l2: fix possible use-after-free in adv7511_remove()Yang Yingliang1-1/+1
[ Upstream commit 2c9541720c66899adf6f3600984cf3ef151295ad ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: adv7604: fix possible use-after-free in adv76xx_remove()Yang Yingliang1-1/+1
[ Upstream commit fa56f5f1fe31c2050675fa63b84963ebd504a5b3 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-05-11media: tc358743: fix possible use-after-free in tc358743_remove()Yang Yingliang1-1/+1
[ Upstream commit 6107a4fdf8554a7aa9488bdc835bb010062fa8a9 ] This driver's remove path calls cancel_delayed_work(). However, that function does not wait until the work function finishes. This means that the callback function may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling cancel_delayed_work_sync(), which ensures that the work is properly cancelled, no longer running, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04media: i2c: max9286: fix access to unallocated memoryTomi Valkeinen1-1/+1
commit e88ccf09e79cf33cac40316ba69c820d9eebc82b upstream. The asd allocated with v4l2_async_notifier_add_fwnode_subdev() must be of size max9286_asd, otherwise access to max9286_asd->source will go to unallocated memory. Fixes: 86d37bf31af6 ("media: i2c: max9286: Allocate v4l2_async_subdev dynamically") Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Cc: stable@vger.kernel.org # v5.10+ Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04media: i2c: ov5670: Fix PIXEL_RATE minimum valueJacopo Mondi1-1/+2
[ Upstream commit dc1eb7c9c290cba52937c9a224b22a400bb0ffd7 ] The driver currently reports a single supported value for V4L2_CID_PIXEL_RATE and initializes the control's minimum value to 0, which is very risky, as userspace might accidentally use it as divider when calculating the time duration of a line. Fix this by using as minimum the only supported value when registering the control. Fixes: 5de35c9b8dcd1 ("media: i2c: Add Omnivision OV5670 5M sensor support") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: tvp5150: Fix wrong return value of tvp5150_parse_dt()Zhang Xiaoxu1-0/+1
[ Upstream commit eb08c48132a1f594478ab9fa2b6ee646c3513a49 ] If of_graph_get_endpoint_by_regs() return NULL, it will return 0 rather than an errno, because we doesn't initialize the return value. Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by: Marco Felsch <m.felsch@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: i2c: imx219: Selection compliance fixesHans Verkuil1-8/+9
[ Upstream commit 1ed36ecd1459b653cced8929bfb37dba94b64c5d ] To comply with the intended usage of the V4L2 selection target when used to retrieve a sensor image properties, adjust the rectangles returned by the imx219 driver. The top/left crop coordinates of the TGT_CROP rectangle were set to (0, 0) instead of (8, 8) which is the offset from the larger physical pixel array rectangle. This was also a mismatch with the default values crop rectangle value, so this is corrected. Found with v4l2-compliance. While at it, add V4L2_SEL_TGT_CROP_BOUNDS support: CROP_DEFAULT and CROP_BOUNDS have the same size as the non-active pixels are not readable using the selection API. Found with v4l2-compliance. [reword commit message, use macros for pixel offsets] Fixes: e6d4ef7d58aa7 ("media: i2c: imx219: Implement get_selection") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: rdacm20: Enable GPIO1 explicitlyJacopo Mondi1-2/+11
[ Upstream commit 7fe1d4453fb6bf103d668a19d957a7b2fc21887c ] The MAX9271 GPIO1 line that controls the sensor reset is by default enabled after a serializer chip reset. As rdacm20 does not go through an explicit serializer reset, make sure GPIO1 is enabled to make the camera module driver more robust. Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver") Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: max9271: Fix GPIO enable/disableJacopo Mondi1-4/+4
[ Upstream commit 909a0a189c677307edd461e21fd962784370d27f ] Fix GPIO enable/disable operations which wrongly read the 0x0f register to obtain the current mask of the enabled lines instead of using the correct 0x0e register. Also fix access to bit 0 of the register which is marked as reserved. Fixes: 34009bffc1c6 ("media: i2c: Add RDACM20 driver") Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: max2175: fix max2175_set_csm_mode() error codeDan Carpenter1-1/+1
[ Upstream commit 9b1b0cb0636166187478ef68d5b95f5caea062ec ] This is supposed to return negative error codes but the type is bool so it returns true instead. Fixes: b47b79d8a231 ("[media] media: i2c: max2175: Add MAX2175 support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: imx214: Fix stop streamingDaniel Gomez1-1/+1
[ Upstream commit eeb76afbe8d91e112396c6281cd020725160f006 ] Stop video streaming when requested. When s_stream is called to stop the video streaming, if/else condition calls start_streaming function instead of the one for stopping it. Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver") Signed-off-by: Daniel Gomez <daniel@qtec.com> Signed-off-by: Ricardo Ribalda <ribalda@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30media: ov5640: fix support of BT656 bus modeHugues Fruchet1-37/+45
[ Upstream commit 68579b32e786f9680e7c6b6c7d17e26943bb02b3 ] Fix PCLK polarity not being taken into account. Add comments about BT656 register control. Remove useless ov5640_set_stream_bt656() function. Refine comments about MIPI IO register control. Fixes: 4039b03720f7 ("media: i2c: ov5640: Add support for BT656 mode") Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-08media: tvp7002: fix uninitialized variable warningHans Verkuil1-1/+3
tvp7002.c: In function 'tvp7002_g_register': tvp7002.c:691:11: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] 691 | reg->val = val; | ~~~~~~~~~^~~~~ Just return without setting 'reg' if tvp7002_read returns an error. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-10-08media: s5k5baf: drop 'data' field in struct s5k5baf_fwHans Verkuil1-3/+2
struct s5k5baf_fw ends with this: struct { u16 id; u16 offset; } seq[0]; u16 data[]; }; which is rather confusing and can cause gcc warnings: s5k5baf.c: In function 's5k5baf_load_setfile.isra': s5k5baf.c:390:13: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'struct <anonymous>[0]' [-Wzero-length-bounds] 390 | if (f->seq[i].offset + d <= end) | ~~~~~~^~~ It turns out that 'data[]' is used in only one place and it can easily be replaced by &fw->seq[0].id and 'seq[0]' can be replaced by 'seq[]'. This is both more readable and solved that warnings. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Sylwester Nawrocki <snawrocki@kernel.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-26media: tc358743: cleanup tc358743_cec_isrTom Rix1-5/+7
tc358743_cec_isr is misnammed, it is not the main isr. So rename it to be consistent with its siblings, tc358743_cec_handler. It also does not check if its input parameter 'handled' is is non NULL like its siblings, so add a check. Fixes: a0ec8d1dc42e ("media: tc358743: add CEC support") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-26media: tc358743: initialize variableTom Rix1-1/+1
clang static analysis flags this error tc358743.c:1468:9: warning: Branch condition evaluates to a garbage value return handled ? IRQ_HANDLED : IRQ_NONE; ^~~~~~~ handled should be initialized to false. Fixes: d747b806abf4 ("[media] tc358743: add direct interrupt handling") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: ov8856: Add support for 3264x2448 modeRobert Foss1-0/+215
OV8856 supports 3264x2448 @ 30 FPS, which is added in this commit. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: ov8856: Add support for 1632x1224 modeRobert Foss1-0/+215
OV8856 supports 1632x1224 @ 60 FPS, which is added in this commit. Signed-off-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: max9286: Allocate v4l2_async_subdev dynamicallyLaurent Pinchart1-19/+21
v4l2_async_notifier_add_subdev() requires the asd to be allocated dynamically, but the max9286 driver embeds it in the max9286_source structure. This causes memory corruption when the notifier is destroyed at remove time with v4l2_async_notifier_cleanup(). Fix this issue by registering the asd with v4l2_async_notifier_add_fwnode_subdev(), which allocates it dynamically internally. A new max9286_asd structure is introduced, to store a pointer to the corresonding max9286_source that needs to be accessed from bound and unbind callbacks. There's no need to take an extra explicit reference to the fwnode anymore as v4l2_async_notifier_add_fwnode_subdev() does so internally. While at it, use %u instead of %d to print the unsigned index in the error message from the v4l2_async_notifier_add_fwnode_subdev() error path. Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Fail probe on unsupported bus_typeLad Prabhakar1-0/+7
Fail probe if unsupported bus_type is detected. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Add support for BT656 modeLad Prabhakar1-12/+34
Enable support for BT656 mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Configure HVP lines in s_power callbackLad Prabhakar1-65/+58
Configure HVP lines in s_power callback instead of configuring everytime in ov5640_set_stream_dvp(). Alongside also disable MIPI in DVP mode. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Enable data pins on poweron for DVP modeLad Prabhakar1-33/+40
During testing this sensor on iW-RainboW-G21D-Qseven platform in 8-bit DVP mode with rcar-vin bridge noticed the capture worked fine for the first run (with yavta), but for subsequent runs the bridge driver waited for the frame to be captured. Debugging further noticed the data lines were enabled/disabled in stream on/off callback and dumping the register contents 0x3017/0x3018 in ov5640_set_stream_dvp() reported the correct values, but yet frame capturing failed. To get around this issue data lines are enabled in s_power callback. (Also the sensor remains in power down mode if not streaming so power consumption shouldn't be affected) Fixes: f22996db44e2d ("media: ov5640: add support of DVP parallel interface") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Separate out mipi configuration from s_powerLad Prabhakar1-56/+60
In preparation for adding DVP configuration in s_power callback move mipi configuration into separate function Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: ov5640: Remain in power down for DVP mode unless streamingLad Prabhakar1-3/+16
Keep the sensor in software power down mode and wake up only in ov5640_set_stream_dvp() callback. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-10media: i2c: Remove Alan Chiang's e-mail addressSakari Ailus2-2/+2
Alan Chiang's e-mail address no longer works. Remove it. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-07Merge tag 'v5.9-rc4' into patchworkMauro Carvalho Chehab1-2/+2
Linux 5.9-rc4 * tag 'v5.9-rc4': (1001 commits) Linux 5.9-rc4 io_uring: fix linked deferred ->files cancellation io_uring: fix cancel of deferred reqs with ->files include/linux/log2.h: add missing () around n in roundup_pow_of_two() mm/khugepaged.c: fix khugepaged's request size in collapse_file mm/hugetlb: fix a race between hugetlb sysctl handlers mm/hugetlb: try preferred node first when alloc gigantic page from cma mm/migrate: preserve soft dirty in remove_migration_pte() mm/migrate: remove unnecessary is_zone_device_page() check mm/rmap: fixup copying of soft dirty and uffd ptes mm/migrate: fixup setting UFFD_WP flag mm: madvise: fix vma user-after-free checkpatch: fix the usage of capture group ( ... ) fork: adjust sysctl_max_threads definition to match prototype ipc: adjust proc_ipc_sem_dointvec definition to match prototype mm: track page table modifications in __apply_to_page_range() MAINTAINERS: IA64: mark Status as Odd Fixes only MAINTAINERS: add LLVM maintainers MAINTAINERS: update Cavium/Marvell entries mm: slub: fix conversion of freelist_corrupted() ...
2020-09-03media: rc: harmonize infrared durations to microsecondsSean Young1-1/+1
rc-core kapi uses nanoseconds for infrared durations for receiving, and microseconds for sending. The uapi already uses microseconds for both, so this patch does not change the uapi. Infrared durations do not need nanosecond resolution. IR protocols do not have durations shorter than about 100 microseconds. Some IR hardware offers 250 microseconds resolution, which is sufficient for most protocols. Better hardware has 50 microsecond resolution and is enough for every protocol I am aware off. Unify on microseconds everywhere. This simplifies the code since less conversion between microseconds and nanoseconds needs to be done. This affects: - rx_resolution member of struct rc_dev - timeout member of struct rc_dev - duration member in struct ir_raw_event Cc: "Bruno Prémont" <bonbons@linux-vserver.org> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Maxim Levitsky <maximlevitsky@gmail.com> Cc: Patrick Lerda <patrick9876@free.fr> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Sean Wang <sean.wang@mediatek.com> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Chen-Yu Tsai <wens@csie.org> Cc: "David Härdeman" <david@hardeman.nu> Cc: Benjamin Valentin <benpicco@googlemail.com> Cc: Antti Palosaari <crope@iki.fi> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov5675: correct the maximum exposure valueBingbu Cao1-5/+10
The unit of exposure value is different from other OmniVision sensors, driver will divide by 2 before set register, the exposure range exposed by v4l2 ctrl to user should be same as others, so the calculation for the maximum exposure value in current driver need be fixed. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov7740: use SCCB regmapRaag Jadav2-10/+2
Make use of SCCB APIs for regmap operations. Remove i2c_check_functionality as devm_regmap_init_sccb does it for us. Signed-off-by: Raag Jadav <raagjadav@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: imx274: fix frame interval handlingHans Verkuil1-3/+5
1) the numerator and/or denominator might be 0, in that case fall back to the default frame interval. This is per the spec and this caused a v4l2-compliance failure. 2) the updated frame interval wasn't returned in the s_frame_interval subdev op. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: m5mols: Check function pointer in m5mols_sensor_powerTom Rix1-1/+2
clang static analysis reports this error m5mols_core.c:767:4: warning: Called function pointer is null (null dereference) [core.CallAndMessage] info->set_power(&client->dev, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In other places, the set_power ptr is checked. So add a check. Fixes: bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: i2c: fix error check on max9286_read callColin Ian King1-1/+2
Currently the error return from the call to max9286_read is masked with 0xf0 so the following check for a negative error return is never true. Fix this by checking for an error first, then masking the return value for subsequent conflink_mask checking. Addresses-Coverity: ("Logically dead code") Fixes: 66d8c9d2422d ("media: i2c: Add MAX9286 driver") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: ov5640: Correct Bit Div register in clock tree diagramPaul Kocialkowski1-1/+1
Although the code is correct and doing the right thing, the clock diagram showed the wrong register for the bit divider, which had me doubting the understanding of the tree. Fix this to avoid doubts in the future. Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Fixes: aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate") Acked-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-09-01media: i2c: ov2740: get OTP data ready before nvmem registrationBingbu Cao1-12/+12
The OTP data was not ready after registered as nvmem device, it is risky as the nvmem read may happen once the device exists, this patch get the OTP data ready before registering the nvmem device. OTP data missing should not break the normal camera sensor probe, so use a warning instead of an error message. Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: Qingwu Zhang <qingwu.zhang@intel.com> Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org> Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-29media: Use fallthrough pseudo-keywordGustavo A. R. Silva10-18/+18
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-08-29media: i2c: tda1997x.c: Fix assignment of 0/1 to bool variableDaniel W. S. Almeida1-3/+3
Fix the following coccinelle reports: drivers/media/i2c/tda1997x.c:911:6-21: WARNING: Assignment of 0/1 to bool variable drivers/media/i2c/tda1997x.c:939:2-17: WARNING: Assignment of 0/1 to bool variable drivers/media/i2c/tda1997x.c:947:4-19: WARNING: Assignment of 0/1 to bool variable Replace assignment to 1 with true and assignment to 0 with false. Found using - Coccinelle (http://coccinelle.lip6.fr) Signed-off-by: Daniel W. S. Almeida <dwlsalmeida@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-25 04:05:02 +0300