- 06 Feb, 2023 11 commits
-
-
Alexander Stein authored
This is not need anyway as the i2c_client is stored in v4l2_subdev. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by:
Daniele Alessandrelli <daniele.alessandrelli@intel.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Laurent Pinchart authored
Replace usage of the deprecated media graph walk API with the new media_pipeline_for_each_pad() macro. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
Replace usage of the deprecated media graph walk API with the new media_pipeline_for_each_entity() and media_pipeline_for_each_pad() macros. Even though the entity iterator may seem a better match when build the entity bitmap in iss_video_stream(), it would not be more efficient as it would still iterate internally over all pads. As the entity iterator requires explicit iterator initialization and cleanup calls, the code would be more complex. Signed-off-by:
-
Laurent Pinchart authored
Replace usage of the deprecated media graph walk API with the new media_pipeline_for_each_entity() macro. Signed-off-by:
-
Laurent Pinchart authored
Add a media_pipeline_for_each_entity() macro to iterate over entities in a pipeline. This should be used by driver as a replacement of the media_graph_walk API, as iterating over the media_pipeline uses the cached list of pads and is thus more efficient. Deprecate the media_graph_walk API to indicate it shouldn't be used in new drivers. Signed-off-by:
-
Laurent Pinchart authored
Add a media_pipeline_for_each_pad() macro to iterate over pads in a pipeline. This should be used by driver as a replacement of the media_graph_walk API, as iterating over the media_pipeline uses the cached list of pads and is thus more efficient. Signed-off-by:
-
Jai Luthra authored
Some module manufacturers [1][2] don't expose the RESETB and PWDN pins of the sensor directly through the 15-pin FFC connector. Instead wiring ~PWDN gpio to the sensor pins with appropriate delays. In such cases, reset_gpio will not be available to the driver, but it will still be toggled when the sensor is powered on, and thus we should still honor the wait time of >= 5ms + 1ms + 20ms (see figure 2-3 in [3]) before attempting any i/o operations over SCCB. Also, rename the function to ov5640_powerup_sequence to better match the datasheet (section 2.7). [1] https://digilent.com/reference/_media/reference/add-ons/pcam-5c/pcam_5c_sch.pdf [2] https://www.alinx.com/public/upload/file/AN5641_User_Manual.pdf [3] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Fixes: 19a81c14 ("[media] add Omnivision OV5640 sensor driver") Reported-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Jai Luthra <j-luthra@ti.com> Reviewed-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
-
Jai Luthra authored
Move the register-based reset out of the init_setting[] and into the powerup_sequence function. The sensor is power cycled and reset using the gpio pins so the soft reset is not always necessary. This also ensures that soft reset honors the timing sequence from the datasheet [1]. [1] https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf Fixes: 19a81c14 ("[media] add Omnivision OV5640 sensor driver") Reported-by:
Jacopo Mondi <jacopo.mondi@ideasonaboard.com> Signed-off-by:
-
Andy Shevchenko authored
There is no point to specify asm-generic for the unaligned.h. Drop the 'generic' suffix and move the inclusion to be after the non-media linux/* ones. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by:
-
Andrey Skvortsov authored
Otherwise autosuspend delay doesn't work and power is cut off immediately as device is freed. Signed-off-by:
Andrey Skvortsov <andrej.skvortzov@gmail.com> Signed-off-by:
-
Nicholas Roth authored
Add a driver for OmniVision OV8858 image sensor. The driver currently supports operations with 2 and 4 data lanes, in full resolution and half-binned resolution modes. The driver has been upported from the PinephonePro BSP available at https://gitlab.com/pine64-org/linux.git at commit 8c4a90c12dc2 ("media: i2c: ov8858: Use default subdev name"). Signed-off-by:
Nicholas Roth <nicholas@rothemail.net> Signed-off-by:
-
- 03 Feb, 2023 27 commits
-
-
Jacopo Mondi authored
Add binding schema for the OmniVision OV8858 8 Megapixels camera sensor. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Laurent Pinchart authored
Check the error status returned by imx290_set_data_lanes() in its caller and propagate it. Signed-off-by:
-
Laurent Pinchart authored
There's no need to check for an incorrect number of data lanes in imx290_set_data_lanes() as the value is validated at probe() time. Drop the check. The PHY_LANE_NUM and CSI_LANE_MODE registers are programmed with a value equal to the number of lanes minus one. Compute it instead of handling it in the switch/case. Signed-off-by:
-
Laurent Pinchart authored
There's no need to configure the data lanes in the runtime PM resume handler. Do so in imx290_start_streaming() instead. Signed-off-by:
-
Laurent Pinchart authored
Initializing the subdev before runtime PM means that no subdev initialization can interact with the runtime PM framework. This can be problematic when modifying controls, as the .s_ctrl() handler commonly calls pm_runtime_get_if_in_use(). These code paths are not trivial, making the driver fragile and possibly causing subtle bugs. To make the subdev initialization more robust, initialize runtime PM first. Signed-off-by:
-
Laurent Pinchart authored
Use runtime PM autosuspend to avoid powering off the sensor during fast stop-reconfigure-restart cycles. This also fixes runtime PM handling in the probe function that didn't suspend the device, effectively leaving it resumed forever. While at it, improve documentation of power management in probe() and remove(). Signed-off-by:
-
Laurent Pinchart authored
The imx290_pixfmt structure contains information about formats, currently limited to the bpp value. Extend it with the register settings for each format, and rename it to imx290_format_info to make its purpose clearer. Add a function named imx290_format_info() to look up format info for a media bus code, and use it through the code. This allows dropping the imx290 bpp field as the value is now looked up dynamically. The error handling in imx290_setup_format() can also be dropped, as the format is guaranteed by imx290_set_fmt() to be valid. Signed-off-by:
-
Laurent Pinchart authored
Use the V4L2 subdev active state API to store the active format. This simplifies the driver not only by dropping the imx290 current_format field, but it also allows dropping the imx290 lock, replaced with the state lock. The lock check in imx290_ctrl_update() can be dropped as imx290_set_fmt() can't be called anywmore with which set to ACTIVE before controls are initialized. Signed-off-by:
-
Laurent Pinchart authored
Move the external clock initialization code from probe() to a separate function to improve readability. No functional change intended. Signed-off-by:
-
Laurent Pinchart authored
Improve error handling in the probe() function with dev_err_probe(). Signed-off-by:
-
Laurent Pinchart authored
Make the probe() function more readable by factoring out the DT parsing code to a separate function. No functional change intended. Signed-off-by:
-
Laurent Pinchart authored
The black level programmed in the BLKLEVEL register depends on the output format. The black level value computation is currently performed in imx290_set_ctrl(), in addition to having different black level values in the output-specific register value tables. Move it to a separate function to simplify the imx290_set_ctrl() code. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Laurent Pinchart authored
The hblank, vblank, pixel rate and link frequency values and limits are currently computed when creating controls, in imx290_ctrl_init(), and updated in imx290_ctrl_update(). This duplicates the logic in different places. Simplify the code by setting the control values and limits to hardcoded values when creating the controls, and call imx290_ctrl_update() to then update them. Signed-off-by:
-
Laurent Pinchart authored
Avoid accessing the imx290 current_format and current_mode fields in imx290_calc_pixel_rate() to prepare for the removal of those fields. Among the two callers of the function, imx290_ctrl_update() has an explicit mode pointer already, and we can also give it a format pointer. Use those explicitly. While at it, inline the imx290_get_link_freq() function in imx290_calc_pixel_rate() as it is only called there. Signed-off-by:
-
Laurent Pinchart authored
The imx290_get_link_freq_index() function hides the fact that it relies on the imx290 current_mode field, which obfuscates the code instead of making it more readable. Inline it in the callers, and use the mode pointer we already have in imx290_ctrl_update() instead of using the current_mode field. Signed-off-by:
-
Laurent Pinchart authored
Move the control update code to a separate function to group it with all the control-related code and make imx290_set_fmt() more readable. Signed-off-by:
-
Laurent Pinchart authored
The probe() function is large. Make it more readable by factoring the subdev initialization code out. While at it, rename the error labels as the "free_" prefix isn't accurate. No functional change intended. Signed-off-by:
-
Laurent Pinchart authored
Move functions around to group them in logical sections, in order to improve readability. As a result, the IMX290_NUM_SUPPLIES macro has to be changed. No other code change is included, only moves. Signed-off-by:
-
Guoniu.zhou authored
In commit a89f14bb ("media: ov5640: Split DVP and CSI-2 formats"), it splits format list for DVP and CSI-2 mode, but the default format defined in commit 90b0f355 ("media: ov5640: Implement init_cfg") is only supported by DVP mode, so define a new default format for CSI-2 mode. Signed-off-by:
Guoniu.zhou <guoniu.zhou@nxp.com> Reviewed-by:
-
Adam Ford authored
The imx219 camera is capable of either two-lane or four-lane operation. When operating in four-lane, both the pixel rate and link frequency change. Regardless of the mode, however, both frequencies remain fixed. Helper functions are needed to read and set pixel and link frequencies which also reduces the number of fixed registers in the table of modes. Signed-off-by:
Adam Ford <aford173@gmail.com> Signed-off-by:
-
Adam Ford authored
There are four modes, and each mode has a table of registers. Some of the registers are common to all modes, so create new tables for these common registers to reduce duplicate code. Signed-off-by:
-
Marco Felsch authored
Using the u64 v4l2_dbg_register.val directly can lead to unexpected results depending on machine endianness. Fix this by using a local variable which is assigned afterwards. Since tc358746_read() will init the val variable to 0 we can assing it without checking the return value first. Addresses-Coverity-ID: 1527256 ("Integer handling issues") Reported-by:coverity-bot <keescook+coverity-bot@chromium.org> Fixes: 80a21da3 ("media: tc358746: add Toshiba TC358746 Parallel to CSI-2 bridge driver") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
Currently we ignore the return value of tc358746_read() and return alawys return 0 which is wrong. Fix this by returning the actual return value of the read operation which is either 0 on success or an error value. Addresses-Coverity-ID: 1527254 ("Error handling issues") Reported-by: -
Marco Felsch authored
It was intended to return an error if tc358746_update_bits() call fail. Fix this by storing the return code. Addresses-Coverity-ID: 1527252 ("Control flow issues") Reported-by: -
Shang XiaoJing authored
There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock device: AssertionError: unreferenced object 0xffff888107362160 (size 16): comm "python3", pid 277, jiffies 4294832798 (age 20.722s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000abe7d67c>] __kmalloc_node+0x44/0x1b0 [<000000008a725aac>] kvmalloc_node+0x34/0x180 [<000000009a53cd11>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000055b46db0>] ov5675_probe+0x38b/0x897 [ov5675] [<00000000153d886c>] i2c_device_probe+0x28d/0x680 [<000000004afb7e8f>] really_probe+0x17c/0x3f0 [<00000000ff2f18e4>] __driver_probe_device+0xe3/0x170 [<000000000a001029>] driver_probe_device+0x49/0x120 [<00000000e39743c7>] __device_attach_driver+0xf7/0x150 [<00000000d32fd070>] bus_for_each_drv+0x114/0x180 [<000000009083ac41>] __device_attach+0x1e5/0x2d0 [<0000000015b4a830>] bus_probe_device+0x126/0x140 [<000000007813deaf>] device_add+0x810/0x1130 [<000000007becb867>] i2c_new_client_device+0x386/0x540 [<000000007f9cf4b4>] of_i2c_register_device+0xf1/0x110 [<00000000ebfdd032>] of_i2c_notify+0xfc/0x1f0 ov5675_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: bf27502b ("media: ov5675: Add support for OV5675 sensor") Signed-off-by:Shang XiaoJing <shangxiaojing@huawei.com> Signed-off-by:
-
Shang XiaoJing authored
There is a kmemleak when testing the media/i2c/ov2740.c with bpf mock device: unreferenced object 0xffff8881090e19e0 (size 16): comm "51-i2c-ov2740", pid 278, jiffies 4294781584 (age 23.613s) hex dump (first 16 bytes): 00 f3 7c 0b 81 88 ff ff 80 75 6a 09 81 88 ff ff ..|......uj..... backtrace: [<000000004e9fad8f>] __kmalloc_node+0x44/0x1b0 [<0000000039c802f4>] kvmalloc_node+0x34/0x180 [<000000009b8b5c63>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<0000000038644056>] ov2740_probe+0x37d/0x84f [ov2740] [<0000000092489f59>] i2c_device_probe+0x28d/0x680 [<000000001038babe>] really_probe+0x17c/0x3f0 [<0000000098c7af1c>] __driver_probe_device+0xe3/0x170 [<00000000e1b3dc24>] device_driver_attach+0x34/0x80 [<000000005a04a34d>] bind_store+0x10b/0x1a0 [<00000000ce25d4f2>] drv_attr_store+0x49/0x70 [<000000007d9f4e9a>] sysfs_kf_write+0x8c/0xb0 [<00000000be6cff0f>] kernfs_fop_write_iter+0x216/0x2e0 [<0000000031ddb40a>] vfs_write+0x658/0x810 [<0000000041beecdd>] ksys_write+0xd6/0x1b0 [<0000000023755840>] do_syscall_64+0x38/0x90 [<00000000b2cc2da2>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ov2740_init_controls() won't clean all the allocated resources in fail path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to prevent memleak. Fixes: 866edc89 ("media: i2c: Add ov2740 image sensor driver") Signed-off-by: -
Shang XiaoJing authored
There is a kmemleak when testing the media/i2c/max9286.c with bpf mock device: kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0xffff88810defc400 (size 256): comm "python3", pid 278, jiffies 4294737563 (age 31.978s) hex dump (first 32 bytes): 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ backtrace: [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0 [<000000002f4912b7>] kvmalloc_node+0x34/0x180 [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev] [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286] [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680 [<0000000087529af3>] really_probe+0x17c/0x3f0 [<00000000b08be526>] __driver_probe_device+0xe3/0x170 [<000000004382edea>] driver_probe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180 [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0 [<0000000041cc06b9>] bus_probe_device+0x126/0x140 [<000000002309860d>] device_add+0x810/0x1130 [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0 [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110 max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free the created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl. Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver") Signed-off-by:
-
- 22 Jan, 2023 2 commits
-
-
Hans Verkuil authored
The tm6000 driver does not use the vb2 framework for streaming video, instead it uses the old vb1 framework and nobody stepped in to convert this driver to vb2. The hardware is very old, so the decision was made to remove it altogether since we want to get rid of the old vb1 framework. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
The vpfe_capture drivers do not use the vb2 framework for streaming video, instead they use the old vb1 framework and nobody stepped in to convert these drivers to vb2. The hardware is very old, so the decision was made to remove them altogether since we want to get rid of the old vb1 framework. Signed-off-by:
Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
