- Mar 09, 2023
-
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://lore.kernel.org/lkml/20221121102838.16448-1-u.kleine-koenig@pengutronix.de Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Wolfram Sang <wsa@kernel.org>
-
Uwe Kleine-König authored
The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Reviewed-by:
-
- Feb 08, 2023
-
-
Hans Verkuil authored
If the media bus is unsupported, then return -EINVAL. Instead it returned 'ret' which happened to be 0. This fixes a smatch warning: ov7670.c:1843 ov7670_parse_dt() warn: missing error code? 'ret' Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Hans Verkuil authored
Since 'ret' is known to be 0, just return '0'. This fixes a smatch warning: s5c73m3-core.c:439 __s5c73m3_s_stream() warn: missing error code? 'ret' Signed-off-by:
-
- Feb 06, 2023
-
-
Dmitry Torokhov authored
There are no existing users of s5c73m3_platform_data in the tree, and new users should either be using device tree, ACPI, or static device properties, so let's remove it from the driver. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Gerald Loacker authored
Add driver for the Sony IMX415 CMOS image sensor. Signed-off-by:
Gerald Loacker <gerald.loacker@wolfvision.net> Co-developed-by:
Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by:
-
Jacopo Mondi authored
The ov5670 driver registers three controls as read-only: - V4L2_CID_PIXEL_RATE - V4L2_CID_LINK_FREQ - V4L2_CID_HBLANK The driver updates the range of HBLANK with __v4l2_ctrl_modify_range() and updates the values of PIXEL_RATE and LINK_FREQ with an explicit call to __v4l2_ctrl_s_ctrl() in ov5670_set_pad_format() time. This causes the .set_ctrl handler to be called on these controls causing a non-fatal warning to be emitted: ov5670_set_ctrl Unhandled id:0x9e0902, val:0x824 This is currently only critical for HBLANK, as LINK_FREQ and PIXEL_RATE currently only support a single value, and the v4l2-ctrl framework skips calling .set_ctrl() if the current control value is not changed. Expand the ov5670_set_ctrl() callback to handle the above controls to remove the above warning and defend against future expansions of the supported pixel rates and link frequencies. Also be stricter and return an error value if a control is actually not handled. Reported-by:
Luca Weiss <luca@z3ntu.xyz> Signed-off-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Tested-by:
-
Jean-Michel Hautbois authored
Add support for the .get_selection() pad operation to the ov5670 sensor driver. Report the native sensor size (pixel array), the crop bounds (readable pixel array area) and the current and default analog crop rectangles. Currently all driver's modes use an analog crop rectangle of size [12, 4, 2600, 1952]. Instead of hardcoding the value in the operation implementation, ad an .analog_crop field to the sensor's modes definitions, to make sure that if any mode gets added, its crop rectangle will be defined as well. While at it re-sort the modes' field definition order to match the declaration order and initialize the crop rectangle in init_cfg(). [Sakari Ailus: Fix a typo on comments (03800 -> 0x3800)] Signed-off-by:
Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
-
Jacopo Mondi authored
Implement the .init_cfg() pad operation and initialize the default format with the default full resolution mode 2592x1944. With .init_cfg() pad operation implemented the deprecated .open() internal operation can now be dropped. Signed-off-by:
-
Jacopo Mondi authored
Implement the runtime resume and suspend routines and install them as runtime_pm handlers. While at it rework the probe() sequence in order to enable runtime_pm before registering the async subdevice. Signed-off-by:
-
Jacopo Mondi authored
The OV5670 has a powerdown and reset pin, named respectively "PWDN" and "XSHUTDOWN". Optionally probe the gpios connected to the pins during the driver probe routine. Signed-off-by:
-
Jacopo Mondi authored
The OV5670 has three power supplies (AVDD, DOVDD and DVDD). Probe them in the driver to prepare controlling with runtime_pm operations. Signed-off-by:
-
Jacopo Mondi authored
Add support for probing the main system clock using the common clock framework and its OF bindings. Maintain ACPI compatibility by falling back to parse 'clock-frequency'. Signed-off-by:
-
Jacopo Mondi authored
The ov5670 driver currently only supports probing using ACPI matching. Add support for OF and add a missing header inclusion. Signed-off-by:
-
Quentin Schulz authored
The sensor has 2592*1944 active pixels, surrounded by 16 active dummy pixels and there are an additional 24 black rows "at the bottom". [2624] +-----+------------------+-----+ | | 16 dummy | | +-----+------------------+-----+ | | | | | | [2592] | | | | | | |16 | valid | 16 |[2000] |dummy| |dummy| | | [1944]| | | | | | +-----+------------------+-----+ | | 16 dummy | | +-----+------------------+-----+ | | 24 black lines | | +-----+------------------+-----+ The top-left coordinate is gotten from the registers specified in the modes which are identical for both currently supported modes. There are currently two modes supported by this driver: 2592*1944 and 1296*972. The second mode is obtained thanks to subsampling while keeping the same field of view (FoV). No cropping involved, hence the harcoded values. Signed-off-by:Quentin Schulz <quentin.schulz@theobroma-systems.com> Reviewed-by:
Jacopo Mondi <jacopo@jmondi.org> Signed-off-by:
-
Quentin Schulz authored
Parse V4L2 device tree properties and register controls for them. Reviewed-by:
-
Quentin Schulz authored
Until now, this driver only supported ACPI. This adds support for Device Tree too while enabling clock and regulators in runtime PM. Signed-off-by:
-
Jai Luthra authored
2x2 binning works fine for RAW10 capture, but for RAW8 1232p mode it leads to corrupted frames [1][2]. Using the special 2x2 analog binning mode fixes the issue, but causes artefacts for RAW10 1232p capture. So here we choose the binning mode depending upon the frame format selected. As both binning modes work fine for 480p RAW8 and RAW10 capture, it can share the same code path as 1232p for selecting binning mode. [1] https://forums.raspberrypi.com/viewtopic.php?t=332103 [2] https://github.com/raspberrypi/libcamera-apps/issues/281 Fixes: 22da1d56 ("media: i2c: imx219: Add support for RAW8 bit bayer format") Signed-off-by:
Jai Luthra <j-luthra@ti.com> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Laurent Pinchart authored
The IMX296LLR is a monochrome 1.60MP CMOS sensor from Sony. The driver supports cropping and binning (but not both at the same time due to hardware limitations) and exposure, gain, vertical blanking and test pattern controls. Preliminary support is also included for the color IMX296LQR sensor. [Sakari Ailus: Make driver's remove function return void] Signed-off-by:
-
Paul Elder authored
Gain control is badly documented in publicly available (including leaked) documentation. There is an AGC pre-gain in register 0x3a13, expressed as a 6-bit value (plus an enable bit in bit 6). The driver hardcodes it to 0x43, which one application note states is equal to x1.047. The documentation also states that 0x40 is equel to x1.000. The pre-gain thus seems to be expressed as in 1/64 increments, and thus ranges from x1.00 to x1.984. What the pre-gain does is however unspecified. There is then an AGC gain limit, in registers 0x3a18 and 0x3a19, expressed as a 10-bit "real gain format" value. One application note sets it to 0x00f8 and states it is equal to x15.5, so it appears to be expressed in 1/16 increments, up to x63.9375. The manual gain is stored in registers 0x350a and 0x350b, also as a 10-bit "real gain format" value. It is documented in the application note as a Q6.4 values, up to x63.9375. One version of the datasheet indicates that the sensor supports a digital gain: The OV5640 supports 1/2/4 digital gain. Normally, the gain is controlled automatically by the automatic gain control (AGC) block. It isn't clear how that would be controlled manually. There appears to be no indication regarding whether the gain controlled through registers 0x350a and 0x350b is an analogue gain only or also includes digital gain. The words "real gain" don't necessarily mean "combined analogue and digital gains". Some OmniVision sensors (such as the OV8858) are documented as supoprting different formats for the gain values, selectable through a register bit, and they are called "real gain format" and "sensor gain format". For that sensor, we have (one of) the gain registers documented as 0x3503[2]=0, gain[7:0] is real gain format, where low 4 bits are fraction bits, for example, 0x10 is 1x gain, 0x28 is 2.5x gain If 0x3503[2]=1, gain[7:0] is sensor gain format, gain[7:4] is coarse gain, 00000: 1x, 00001: 2x, 00011: 4x, 00111: 8x, gain[7] is 1, gain[3:0] is fine gain. For example, 0x10 is 1x gain, 0x30 is 2x gain, 0x70 is 4x gain (The second part of the text makes little sense) "Real gain" may thus refer to the combination of the coarse and fine analogue gains as a single value. The OV5640 0x350a and 0x350b registers thus appear to control analogue gain. The driver incorrectly uses V4L2_CID_GAIN as V4L2 has a specific control for analogue gain, V4L2_CID_ANALOGUE_GAIN. Use it. If registers 0x350a and 0x350b are later found to control digital gain as well, the driver could then restrict the range of the analogue gain control value to lower than x64 and add a separate digital gain control. Signed-off-by:
Paul Elder <paul.elder@ideasonboard.com> Signed-off-by:
-
Yuan Can authored
A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked. Fixes: 1112babd ("media: i2c: Copy ov772x soc_camera sensor driver") Signed-off-by:Yuan Can <yuancan@huawei.com> Reviewed-by:
-
Yassine Oudjana authored
Make the driver get needed regulators on probe and enable/disable them on runtime PM callbacks. Signed-off-by:
Yassine Oudjana <y.oudjana@protonmail.com> Tested-by:
Umang Jain <umang.jain@ideasonboard.com> Signed-off-by:
-
Alexander Stein authored
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Alexander Stein authored
This is not need anyway as the i2c_client is stored in v4l2_subdev. Signed-off-by:
Daniele Alessandrelli <daniele.alessandrelli@intel.com> 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 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:
-
- Feb 03, 2023
-
-
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:
-
