- 08 Jul, 2022 40 commits
-
-
Jacopo Mondi authored
The ov5640 driver supports different sizes for different mbus_codes. In particular: - 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720) Adjust the image sizes according to the above constraints. Signed-off-by:
Jacopo Mondi <jacopo@jmondi.org> 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@kernel.org>
-
Jacopo Mondi authored
The ov5640 driver supports different sizes for different mbus_codes. In particular: - 8bpp modes: high resolution sizes (>= 1280x720) - 16bpp modes: all sizes - 24bpp modes: low resolutions sizes (< 1280x720) Restrict the frame sizes enumerations to the above constraints. While at it, make sure the fse->mbus_code parameter is valid, and return -EINVAL if it's not. Signed-off-by:
-
Jacopo Mondi authored
Add support for BGR888 image format. No existing media bus codes describe exactly the way data is transferred on the CSI-2 bus. This is not a new issue, the CSI-2 YUV422 8-bit format is described by MEDIA_BUS_FMT_UYVY8_1X16 which is an arbitrary convention and not an exact match. Use the MEDIA_BUS_FMT_BGR888_1X24 to follow the same convention, based on the order in which bits are transmitted over the CSI-2 bus when producing images in RGB24 format. Signed-off-by:
-
Jacopo Mondi authored
The driver already supports the 2X8_[LE|BE] variants of RGB565 formats. As for CSI-2 the 2X8 variants do not apply, add RGB565_1X16 variant with little-endian ordering of components as required by the CSI-2 specifications. Signed-off-by:
-
Jacopo Mondi authored
Parse the device properties and register the rotation and orientation V4L2 controls using v4l2_ctrl_new_fwnode_properties(). Remove the open-coded parsing of the rotation property and assume the DTS is correct is providing either <0> or <180> as possible rotations. Signed-off-by:
-
Jacopo Mondi authored
Implement the get_selection pad operation for the OV5640 sensor driver. The supported targets report the sensor's native size, the active pixel array size and the analog crop rectangle from which the image is produced. Signed-off-by:
-
Jacopo Mondi authored
Implement the init_cfg pad operation to initialize the subdev state format to the default one. Signed-off-by:
-
Jacopo Mondi authored
Now that the frame duration can be controlled by tuning the VBLANK duration in CSI-2 mode, fix all modes definitions to comply with the reported FPS. All modes run at 30 FPS except for full-resolution mode 2592x1944 which runs at 15FPS. Tested on a 2 data lanes setup in UYVY and RGB565 modes in CSI-2 mode. Signed-off-by:
-
Jacopo Mondi authored
The current implementation of ov5640_find_mode() fails if the frame rate programmed with s_frame_interval doesn't match the maximum frame rate for the current mode. This causes issues when moving from one mode with higher FPS to another one which only supports a lower FPS range with tools like media-ctl. It also forces users that do not use s_frame_interval(), but rather configure blankings explicitly, to adjust the programmed FPS range to avoid failures. For this reason, remove the FPS check from ov5640_find_mode() and only perform it at s_frame_interval() time. Signed-off-by:
-
Hugues Fruchet authored
Adjust the vertical blanking when s_frame_interval is used. s_frame_interval allows to set a fixed frame rate, which gets stored as the sensor's current one. When a new mode is applied, the current frame rate is reset to the mode's default one. In order to correctly report the currently configured vertical blanking for s_frame_interval users, verify that the desired frame rate has not been changed. If that's the case, compute the correct blanking value and reflect it through the corresponding v4l2 control. Signed-off-by:
Hugues Fruchet <hugues.fruchet@st.com> Signed-off-by:
-
Jacopo Mondi authored
Add the VBLANK control which allows to select the duration of the frame vertical blankings and allows to control the framerate. The VBLANK control also modifies the exposure time range, which cannot exceed the maximum frame length. Signed-off-by:
-
Jacopo Mondi authored
Add the HBLANK control as read-only. The hblank value is fixed in the mode definition and is updated everytime a new format is applied. Signed-off-by:
-
Jacopo Mondi authored
The ov5640_mode_init_data is a fictional sensor more which is used to program the initial sensor settings. It is only used to initialize the sensor and can be replaced it with a throw-away mode which just wraps the register table. Also rename the register table to drop the format from the name to make it clear an actual sensor mode has to be applied after the initial programming. Signed-off-by:
-
Jacopo Mondi authored
The register tables for all resolutions smaller than 720p are now identical. Remove the duplicated ones and create a single ov5640_setting_low_res[] register table. Signed-off-by:
-
Jacopo Mondi authored
The per-mode register tables are not sorted by size. Fix it. Cosmetic change only. Signed-off-by:
-
Jacopo Mondi authored
Provide a function to shortcut access to the correct timings definition to avoid repeating the same pattern when accessing the sensor timings. Signed-off-by:
-
Jacopo Mondi authored
Separate the timings for the DVP mode from the timings for the CSI-2 mode in the ov5640 modes definition. The CSI-2 timings will deviate from the DVP ones as the clock tree is calculated differently. In CSI-2 mode change the analog crop rectangles as the OV5640 pixel array is composed as: - vertically: 16 dummy columns, 2592 valid ones and 16 dummy columns for a total of 2624 columns - horizontally: 8 optical black lines, 6 dummy ones, 1944 valid and 6 dummies for a total of 1964 lines Adjust the analog crop rectangle in CSI-2 mode to: - Skip the first 16 dummy columns - Skip the first 14 black/dummy lines - Pass the whole valid pixel array size to the ISP for all modes except 1024x768, 720p and 1080p which are obtained by cropping the valid pixel array. Tested in RGB565, UYVY and RGB888 modes in CSI-2 mode. Signed-off-by:
-
Jacopo Mondi authored
Adjust the left crop of 720x480 to enable capture in RGB888 format, which is otherwise broken. The 56 pixels alignment has been copied from the 720x576 mode. Signed-off-by:
-
Jacopo Mondi authored
The current definition of a sensor mode defines timings as follows: - hact, vact: Visible width and height - htot, vtot: Total sizes including blankings This makes difficult to clearly separate the visible sizes from the blankings and to make the vertical blanking programmable. Rework the sensor modes sizes definition to: - Report the analog crop sizes - Report the visible crop size - Report the total pixels per line as HBLANK is fixed - Report the VBLANK value to make it programmable Also modify the ov5640_set_timings() function to program all the windowing registers are remove them from the per-mode register-value tables. Do not change the timing values from the ones reported in the register tables to maintain bisectability. Signed-off-by:
-
Jacopo Mondi authored
Re-work the ov5640_set_mipi_pclk() function to calculate the PLL configuration using the pixel_rate and link_freq values set at s_fmt time. Rework the DVP clock mode settings to calculate the pixel clock internally and remove the assumption on the 16bpp format. Tested in MIPI CSI-2 mode with 1 and 2 data lanes with: - all the sensor supported resolutions in UYVY, RGB565 and MJPEG formats. - resolutions >= 1280x720 in RAW Bayer format. - resolutions < 1280x720 in RGB888 format. [Rework pclk_period and link_freq computation] Signed-off-by:
-
Jacopo Mondi authored
After having set a new format re-calculate the pixel_rate and link_freq control values and update them when in MIPI mode. Take into account the limitation of the link frequency having to be strictly smaller than 1GHz when computing the desired link_freq, and adjust the resulting pixel_rate acounting for the clock tree configuration. [Adjust link_freq calculation] Signed-off-by:
-
Jacopo Mondi authored
Add the V4L2_CID_LINK_FREQ control to the ov5640 driver. Make the control read-only for the moment. Signed-off-by:
-
Jacopo Mondi authored
Associate the bit depth to each format supported by the sensor. The bpp will be used to calculate the line length. Signed-off-by:
-
Jacopo Mondi authored
Checking if the sensor is used in DVP or MIPI CSI-2 mode is a repeated pattern which is about to be repeated more often. Provide an inline function to shortcut that. Signed-off-by:
-
Jacopo Mondi authored
The array of supported modes is close to unreadable. Re-arrange it giving it some room to breath. Cosmetic change only. Signed-off-by:
-
Jacopo Mondi authored
Add to each mode supported by the sensor the ideal pixel rate, as defined by Table 2.1 in the chip manual. The ideal pixel rate will be used to compute the MIPI CSI-2 clock tree. Signed-off-by:
-
Hugues Fruchet authored
Add support of 1X16 serial pixel formats in order to support CSI-2 camera sensor exposing 1x16 pixel formats only. Signed-off-by:
-
Hugues Fruchet authored
Expose RGB & YUV 1X16 serial pixel format variants to comply with CSI-2 camera sensor pixel formats. Signed-off-by:
Hugues Fruchet <hugues.fruchet@foss.st.com> Reviewed-by:
Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by:
-
Alain Volmat authored
Those two formats were missing in the list of supported MBUS formats. Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com> Reviewed-by:
-
Hugues Fruchet authored
Add support of pixel clock polarity. Signed-off-by:
-
Sakari Ailus authored
The s_stream callback had several issues: - If pm_runtime_get_sync() fails, the usage_count is not put. - The sensor wasn't suspended if s_stream(subdev, 1) failed. Fix this. Fixes: ("media: i2c: Add pm_runtime support to ov7251") Signed-off-by: -
Paul Kocialkowski authored
The A83T supports MIPI CSI-2 with a composite controller, covering both the protocol logic and the D-PHY implementation. This controller seems to be found on the A83T only and probably was abandoned since. This implementation splits the protocol and D-PHY registers and uses the PHY framework internally. The D-PHY is not registered as a standalone PHY driver since it cannot be used with any other controller. There are a few notable points about the controller: - The initialisation sequence involes writing specific magic init values that do not seem to make any particular sense given the concerned register fields; - Interrupts appear to be hitting regardless of the interrupt mask registers, which can cause a serious flood when transmission errors occur. Only 8-bit and 10-bit Bayer formats are currently supported. While up to 4 internal channels to the CSI controller exist, only one is currently supported by this implementation. This work is based on the first version of the driver submitted by Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP. This version integrates MIPI CSI-2 support as a standalone V4L2 subdev instead of merging it in the sun6i-csi driver. It was tested on a Banana Pi M3 board with an OV8865 sensor in a 4-lane configuration. Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Paul Kocialkowski authored
This introduces YAML bindings documentation for the Allwinner A83T MIPI CSI-2 controller. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Paul Kocialkowski authored
Add myself as maintainer of the Allwinner A31 MIPI CSI-2 bridge media driver. Signed-off-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
-
Paul Kocialkowski authored
The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge found on Allwinner SoCs such as the A31 and V3/V3s. It is a standalone block, connected to the CSI controller on one side and to the MIPI D-PHY block on the other. It has a dedicated address space, interrupt line and clock. It is represented as a V4L2 subdev to the CSI controller and takes a MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and media controller API. Only 8-bit and 10-bit Bayer formats are currently supported. While up to 4 internal channels to the CSI controller exist, only one is currently supported by this implementation. Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Paul Kocialkowski authored
This introduces YAML bindings documentation for the Allwinner A31 MIPI CSI-2 controller. Signed-off-by:
-
Paul Kocialkowski authored
The A31 CSI controller supports two distinct input interfaces: parallel and an external MIPI CSI-2 bridge. The parallel interface is often connected to a set of hardware pins while the MIPI CSI-2 bridge is an internal FIFO-ish link. As a result, these two inputs are distinguished as two different ports. Note that only one of the two may be present on a controller instance. For example, the V3s has one controller dedicated to MIPI-CSI2 and one dedicated to parallel. Update the binding with an explicit ports node that holds two distinct port nodes: one for parallel input and one for MIPI CSI-2. This is backward-compatible with the single-port approach that was previously taken for representing the parallel interface port, which stays enumerated as fwnode port 0. Note that additional ports may be added in the future, especially to support feeding the CSI controller's output to the ISP. Signed-off-by:
-
Nicolas Frattaroli authored
The RK3566 and RK3568 SoCs come with a small Hantro instance which is solely dedicated to encoding. This patch adds the necessary structs to the Hantro driver to allow the JPEG encoder of it to function. Through some sleuthing through the vendor's MPP source code and after closer inspection of the TRM, it was determined that the hardware likely supports VP8 and H.264 as well. Tested with the following GStreamer command: gst-launch-1.0 videotestsrc ! v4l2jpegenc ! matroskamux ! \ filesink location=foo.mkv Signed-off-by:Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Reviewed-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Nicolas Frattaroli authored
The RK3568 and RK3566 have a Hantro VPU node solely dedicated to encoding. This patch adds a new binding to describe it, as it does not really fit the rockchip-vpu binding, since there is no decoder. Signed-off-by:
-
Ming Qian authored
In reset vpu core, driver will wait for a response event, but if there are still some events unhandled, they will be handled first, driver may acquire core lock for that. So if we do reset in core lock, it may led to reset timeout. Fixes: 9f599f35 ("media: amphion: add vpu core driver") Signed-off-by:
Ming Qian <ming.qian@nxp.com> Signed-off-by:
-
