- 20 Mar, 2023 38 commits
-
-
Jacopo Mondi authored
The ov5670 driver tries to get a reference to the xvclk provider by using the common cock framework and deflects to parsing the "clock-frequency" property in case the clock provider is not specified in the firmware interface, detected by checking if ov5670->xvclk == PTR_ERR(-ENOENT). However, as reported by the Smatch static checker, if CONFIG_HAVE_CLK is not enabled, devm_clk_get() returns 0 which when passed to PTR_ERR() means success causing the driver to fail without propagating any error code up. Explicitly handle the case where ov5670->xvclk it set to NULL, forcing the code to parse the "clock-frequency" property in case CONFIG_HAVE_CLK is not enabled, as suggested by Dan Carpenter. Reported-by:
Dan Carpenter <error27@gmail.com> Suggested-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Krzysztof Kozlowski authored
The st,stm32-cec.yaml was moved to media/cec directory, however the "remove" part disappeared during applying. Link: https://lore.kernel.org/all/20221208103115.25512-3-krzysztof.kozlowski@linaro.org/ Fixes: 8f437662 ("media: dt-bindings: st,stm32-cec: move to cec subfolder") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Luca Weiss authored
Currently the driver always configures the sensor for dual-lane MIPI output, but it also supports single-lane output. Add support for that by checking the data-lanes fwnode property how many lanes are used and configure the necessary registers based on that. To achieve this we move setting register 0x3018 out of the general reg sequence so we set it to the correct value. The pixel_rate value also needs to be adjusted. [Sakari Ailus: Use div_s64 to divide a 64-bit number] Signed-off-by:
Luca Weiss <luca@z3ntu.xyz> Reviewed-by:
-
Luca Weiss authored
Replace the unusual const char *err_msg usage with dev_err_probe which also handles -EPROBE_DEFER better by not printing the message to kmsg. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S5C73M3 8Mp camera ISP bindings to DT schema. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S5P/Exynos Camera Subsystem (FIMC) bindings to DT schema. Changes during conversion - adjust to existing DTS and Linux driver: add iommus and power-domains. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung Exynos4212/4412 SoC Imaging Subsystem (FIMC-IS) bindings to DT schema. Changes during conversion - adjust to existing DTS and Linux driver: add iommus and power-domains. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung Exynos SoC series camera host interface (FIMC-LITE) bindings to DT schema. Changes during conversion - adjust to existing DTS and Linux driver: add iommus and power-domains. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS) bindings to DT schema. Changes during conversion - adjust to existing DTS and Linux driver: 1. Add phys and power-domains. 2. Move samsung,csis-wclk property to the endpoint node. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S5K5BAF image sensor bindings to DT schema. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S5K6A3(YX) raw image sensor bindings to DT schema. Signed-off-by:
-
Krzysztof Kozlowski authored
The FIMC camera node wrapper is not a bus, so using simple-bus fallback compatible just to instantiate its children nodes was never correct. Driver should explicitly populate all its children devices. Signed-off-by:
-
Krzysztof Kozlowski authored
Driver does not handle pin configuration switching and several DTS provide empty pinctrl property, just to satisfy the driver's requirement for it. Drop requirement for pinctrl property as it is really optional. Signed-off-by:
-
Krzysztof Kozlowski authored
The FIMC camera node wrapper is not a bus, so using simple-bus fallback compatible just to instantiate its children nodes was never correct. Drop the simple-bus compatible and expect driver to explicitly populate children devices. Signed-off-by:
-
Paul Elder authored
The documentation for the VIDIOC_SUBDEV_ENUM_FRAME_SIZE ioctl incorrectly refers to struct v4l2_subdev_mbus_code_enum as the parameter. Fix this. [Sakari Ailus: Rebased on top of Dorota's documentation patch] Signed-off-by:
Paul Elder <paul.elder@ideasonboard.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Dorota Czaplejewicz authored
This clarifies which side of the calls is responsible for doing what to which parts of the struct. It also expands the terse description of the access algorithm into more prose-like, active voice description, which trades conciseness for ease of comprehension. Fixed: typo "format" -> "frame size" in enum-frame-size Added: no holes in the enumeration Added: enumerations per what? Added: who fills in what in calls Changed: "given" -> "specified" [Sakari Ailus: Rewrap text] Signed-off-by:
Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Acked-by:
-
Dorota Czaplejewicz authored
This clarifies which side of the calls is responsible for doing what to which parts of the struct. This also explicitly states that repeating values are disallowed. It also expands the terse description of the access algorithm into more prose-like, active voice description, which trades conciseness for ease of comprehension. Added: mbus codes must not repeat Added: no holes in the enumeration Added: enumerations per what? Added: who fills in what in calls Changed: "zero" -> "0" Changed: "given" -> "specified" Still unclear how it works so didn't describe: "which". What is a "try format" vs "active format"? [Sakari Ailus: Rewrap lines, fix build issue] Signed-off-by:
-
Alexander Stein authored
Both sensors are quite similar. Their specs only differ regarding LVDS and parallel output but are identical regarding MIPI-CSI-2 interface. But they use a different init setting of hard-coded values, taken from the datasheet. Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
-
Alexander Stein authored
The imx290 driver can be used for both imx290 and imx327 as they have a similar register set and configuration. imx327 lacks 8 lanes LVDS and 120 FPS support. Signed-off-by:
-
Dave Stevenson authored
imx290_start_streaming logs what failed, but not the error code from that function. Add it into the log message. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Dave Stevenson authored
The sensor supports H & V flips, so add the relevant hooks for V4L2_CID_HFLIP and V4L2_CID_VFLIP to configure them. Note that the Bayer order is maintained as the readout area shifts by 1 pixel in the appropriate direction (note the comment about the top margin being 8 pixels whilst the bottom margin is 9). The V4L2_SEL_TGT_CROP region is therefore adjusted appropriately. Signed-off-by:
-
Dave Stevenson authored
The sensor supports either a 37.125 or 74.25MHz external, but the driver only supported 37.125MHz. Add the relevant register configuration for either clock frequency option. Signed-off-by:
-
Dave Stevenson authored
IMX290_CTRL_07 was written from both imx290_global_init_settings and imx290_1080p_settings and imx290_720p_settings. Remove it from imx290_global_init_settings as the setting varies based on the mode. Signed-off-by:
-
Dave Stevenson authored
The default VMAX for 60fps in 720p mode is 750 according to the datasheet, however the driver always left it at 1125 thereby stopping 60fps being achieved. Make VMAX (and therefore V4L2_CID_VBLANK) mode dependent so that 720p60 can be achieved. Signed-off-by:
-
Dave Stevenson authored
The driver exposed V4L2_CID_VBLANK as a read only control to allow for exposure calculations and determination of the frame rate. Convert to a read/write control so that the frame rate can be controlled. V4L2_CID_VBLANK also sets the limits for the exposure control, therefore exposure ranges have to be updated when vblank changes (either via s_ctrl, or via changing mode). Signed-off-by:
-
Dave Stevenson authored
The driver exposed V4L2_CID_HBLANK as a read only control to allow for exposure calculations and determination of the frame rate. Convert to a read/write control so that the frame rate can be controlled. Signed-off-by:
-
Dave Stevenson authored
Commit "98e0500e media: i2c: imx290: Add configurable link frequency and pixel rate" added support for the increased link frequencies on 2 data lanes, but didn't update the CSI timing registers in accordance with the datasheet. Use the specified settings. Signed-off-by:
-
Dave Stevenson authored
Commit "97589ad6 media: i2c: imx290: Add support for 2 data lanes" added support for running in two lane mode (instead of 4), but without changing the link frequency that resulted in a max of 30fps. Commit "98e0500e media: i2c: imx290: Add configurable link frequency and pixel rate" then doubled the link frequency when in 2 lane mode, but didn't undo the correction for running at only 30fps, just extending horizontal blanking instead. Remove the 30fps limit on 2 lane by correcting the register config in accordance with the datasheet for 60fps operation over 2 lanes. Signed-off-by:
-
Dave Stevenson authored
The datasheet lists the link frequency changes between 1080p and 720p modes. This is correct that the link frequency changes as measured on an oscilloscope. Link frequency is not necessarily the same as pixel rate. The datasheet gives standard configurations for 1080p and 720p modes at a number of frame rates. Looking at the 1080p mode it gives: HMAX = 0x898 = 2200 VMAX = 0x465 = 1125 2200 * 1125 * 60fps = 148.5MPix/s Looking at the 720p mode it gives: HMAX = 0xce4 = 3300 VMAX = 0x2ee = 750 3300 * 750 * 60fps = 148.5Mpix/s This driver currently scales the pixel rate proportionally to the link frequency, however the above shows that this is not the correct thing to do, and currently all frame rate and exposure calculations give incorrect results. Correctly report the pixel rate as being 148.5MPix/s under any mode. Signed-off-by:
-
Dave Stevenson authored
Any V4L2 subdevice that implements controls and declares V4L2_SUBDEV_FL_HAS_DEVNODE should also declare V4L2_SUBDEV_FL_HAS_EVENTS and implement subscribe_event and unsubscribe_event hooks. This driver didn't and would therefore fail v4l2-compliance testing. Add the relevant hooks. Signed-off-by:
-
Dave Stevenson authored
The colorspace fields were left untouched in imx290_set_fmt which lead to a v4l2-compliance failure. Signed-off-by:
-
Dave Stevenson authored
Fix up a couple of coding style issues regarding missing blank lines after declarations, double blank lines, and incorrect indentation. Signed-off-by:
-
Dave Stevenson authored
The IMX290 module is available as either mono or colour (Bayer). Update the driver so that it can advertise the correct mono formats instead of the colour ones. Signed-off-by:
-
Dave Stevenson authored
The IMX290 module is available as either monochrome or colour and the variant is not detectable at runtime. Add a new compatible string for the monochrome version, based on the full device name IMX290LLR. For consistency, add a new compatible string for the colour version based on the IMX290LQR full device name, and deprecate the current ambiguous compatible string. Signed-off-by:
-
Jacopo Mondi authored
The ov5647_read() functions calls i2c_master_send() and i2c_master_read() in sequence. However this leaves space for other clients to contend the bus and insert an unrelated transaction in between the two calls. Replace the two calls with a single i2c_transfer() one, that locks the bus in between the transactions. Signed-off-by:
Tommaso Merciai <tomm.merciai@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Valentine Barshak authored
This adds V4L2_CID_TEST_PATTERN control support. Signed-off-by:
Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by:
-
Andy Shevchenko authored
No need to call fwnode_property_read_u32(dev_fwnode()), when we have already existing helper. So use it. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Andy Shevchenko authored
Since we have a proper endianness converters for LE 24-bit data use them. Signed-off-by:
-
- 19 Mar, 2023 2 commits
-
-
Tomi Valkeinen authored
A common case with subdev routing is that on the subdevice just before the DMA engines (video nodes), no multiplexing is allowed on the source pads, as the DMA engine can only handle a single stream. In some other situations one might also want to do the same check on the sink side. Add new routing validation flags to check these: V4L2_SUBDEV_ROUTING_NO_SINK_MULTIPLEXING and V4L2_SUBDEV_ROUTING_NO_SOURCE_MULTIPLEXING. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
Tomi Valkeinen authored
V4L2_SUBDEV_ROUTING_NO_STREAM_MIX routing validation flag means that all routes from a sink pad must go to the same source pad and all routes going to the same source pad must originate from the same sink pad. This does not cover all use cases. For example, if a device routes all streams from a single sink pad to any of the source pads, but streams from multiple sink pads can go to the same source pad, the current flag is too restrictive. Split the flag into two parts, V4L2_SUBDEV_ROUTING_NO_SINK_STREAM_MIX and V4L2_SUBDEV_ROUTING_NO_SOURCE_STREAM_MIX, which add the restriction only on one side of the device. Together they mean the same as V4L2_SUBDEV_ROUTING_NO_STREAM_MIX. Signed-off-by:
-
