Integrate meta-seco-rk/linux-seco-rk/niccolor/e09-csi-cameras-ov5640 (!894) · Merge requests · Clea OS / seco-manifest

Commit: clea-os/layers/seco/meta-seco-rk@853ee387

Integrate linux-seco-rk/niccolor/e09-csi-cameras-ov5640

Commit: clea-os/bsp/rockchip/linux-seco-rk@b558162e

[DRIVER][CAMERA] media: i2c: ov5640: change default fmt from UYVY to YUYV

With this default gst-launch-1.0 -v v4l2src device=/dev/video0 ! waylandsink works correctly. With the old fmt the colors are inverted (the image is green and fuchsia)

Commit: clea-os/bsp/rockchip/linux-seco-rk@805741a6

[DRIVER][CAMERA] media: i2c: ov5640: fix ov5640_g_mbus_config function

Go back to the proper configuration supported in kernel 5.10

Commit: clea-os/bsp/rockchip/linux-seco-rk@5a52e74d

[FIX-PATCH] media: i2c: ov5640: Revert temporary update driver code to apply the next patches

Go back to the proper code supported in kernel 5.10 This revert commit 9e78bc421081

Commit: clea-os/bsp/rockchip/linux-seco-rk@43141010

[PATCH] LF-8868: media: ov5640: fix incorrect frame frate issue

If run OV5640 with 640x480@30 setting after power up, the real frame rate for it is 60, not 30. The reason is default frame interval parameter in probe is 30 but default link frequency is to generate 60 frame rate, so correct it.

Signed-off-by: Guoniu.zhou guoniu.zhou@nxp.com Reviewed-by: Robby Cai robby.cai@nxp.com

Commit: clea-os/bsp/rockchip/linux-seco-rk@5b3112a0

[PATCH] media: i2c: ov5640: add Rockchip-specific support

Rockchip extends the base driver with vendor-specific requirements:

Add private ioctl call RKMODULE_GET_MODULE_INFO
Implement specific V4L2 callbacks: g_input_status, get_mbus_config
Read vendor-specific camera module information from device tree
Hardcoded number of MIPI-CSI2 lanes to 2
Use old version of probe instead of probe_new

Commit: clea-os/bsp/rockchip/linux-seco-rk@591036e1

[PATCH] media: ov5640: Fix a memory leak when ov5640_probe fails

[ Upstream commit 20290feaaeb76cc719921aad275ccb18662a7c3a ]

sensor->ctrls.handler is initialized in ov5640_init_controls(), so when the sensor is not connected and ov5640_sensor_resume() fails, sensor->ctrls.handler should be released, otherwise a memory leak will be detected:

unreferenced object 0xc674ca80 (size 64): comm "swapper/0", pid 1, jiffies 4294938337 (age 204.880s) hex dump (first 32 bytes): 80 55 75 c6 80 54 75 c6 00 55 75 c6 80 52 75 c6 .Uu..Tu..Uu..Ru. 00 53 75 c6 00 00 00 00 00 00 00 00 00 00 00 00 .Su..........

Fixes: 85644a9b37ec ("media: ov5640: Use runtime PM") Signed-off-by: Xiaolei Wang xiaolei.wang@windriver.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@fb9c83f6

[PATCH] media: ov5640: fix vblank unchange issue when work at dvp mode

[ Upstream commit 8fc29e3c9f682d4ad9b0764d44ecc6c19b000051 ]

The value of V4L2_CID_VBLANK control is initialized to default vblank value of 640x480 when driver probe. When OV5640 work at DVP mode, the control value won't update and lead to sensor can't output data if the resolution remain the same as last time since incorrect total vertical size. So update it when there is a new value applied.

Fixes: bce93b827de6 ("media: ov5640: Add VBLANK control") Signed-off-by: Guoniu.zhou guoniu.zhou@nxp.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@f0e844b2

[PATCH] media: ov5640: Drop dead code using frame_interval

[ Upstream commit eeaa47d182fedfe68b8fd40ef3798761c8904791 ]

The ov5640_update_pixel_rate() function handles the parallel and MIPI CSI-2 cases separately.

When running on a parallel setup the V4L2_CID_PIXEL_RATE value is calculated at the beginning of the function using the values configured with the frame_interval operations, and then the function immediately returns.

The remaining of the function handles the MIPI CSI-2 configuration and should not use the 'current_fr' and 'def_fps' fields as those are only relevant for parallel mode.

Drop a small section of dead code that updates vblank using frame_interval on a MIPI CSI-2 setup.

Signed-off-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Hans Verkuil hverkuil-cisco@xs4all.nl Stable-dep-of: 8fc29e3c9f68 ("media: ov5640: fix vblank unchange issue when work at dvp mode") Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@52d1cee0

[PATCH] media: ov5640: Fix initial RESETB state and annotate timings

[ Upstream commit a210df337c5f5c2cd82f36c9dbb154ec63365c80 ]

The initial state of RESETB input signal of OV5640 should be asserted, i.e. the sensor should be in reset. This is not the case, make it so.

Since the subsequent assertion of RESETB signal is no longer necessary and the timing of the power sequencing could be slightly adjusted, add annotations to the delays which match OV5640 datasheet rev. 2.03, both: figure 2-3 power up timing with internal DVDD figure 2-4 power up timing with external DVDD source

The 5..10ms delay between PWDN assertion and RESETB assertion is not even documented in the power sequencing diagram, and with this reset fix, it is no longer even necessary.

Fixes: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Signed-off-by: Marek Vasut marex@denx.de Reviewed-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Tested-by: Jai Luthra j-luthra@ti.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@8c7dbabe

[PATCH] media: ov5640: Enable MIPI interface in ov5640_set_power_mipi()

[ Upstream commit 98cb72d3b9c5e03b10fa993752ecfcbd9c572d8c ]

Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means MIPI CSI2 interface, while 0 means CPI parallel interface.

In the ov5640_set_power_mipi() the interface should obviously be set to MIPI CSI2 since this functions is used to power up the sensor when operated in MIPI CSI2 mode. The sensor should not be in CPI mode in that case.

This fixes a corner case where capturing the first frame on i.MX8MN with CSI/ISI resulted in corrupted frame.

Fixes: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Tested-by: Jacopo Mondi jacopo.mondi@ideasonboard.com # [Test on imx6q] Signed-off-by: Marek Vasut marex@denx.de Tested-by: Jai Luthra j-luthra@ti.com # [Test on bplay, sk-am62] Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@ac79856e

[PATCH] media: ov5640: fix low resolution image abnormal issue

[ Upstream commit a828002f38c5ee49d3f0c0e64c0f0caa1aec8dc2 ]

OV5640 will output abnormal image data when work at low resolution (320x240, 176x144 and 160x120) after switching from high resolution, such as 1080P, the time interval between high and low switching must be less than 1000ms in order to OV5640 don't enter suspend state during the time.

The reason is by 0x3824 value don't restore to initialize value when do resolution switching. In high resolution setting array, 0x3824 is set to 0x04, but low resolution setting array remove 0x3824 in commit db15c1957a2d ("media: ov5640: Remove duplicated mode settings"). So when do resolution switching from high to low, such as 1080P to 320x240, and the time interval is less than auto suspend delay time which means global initialize setting array will not be loaded, the output image data are abnormal. Hence move 0x3824 from ov5640_init_setting[] table to ov5640_setting_low_res[] table and also move 0x4407 0x460b, 0x460c to avoid same issue.

Fixes: db15c1957a2d ("media: ov5640: Remove duplicated mode settings") Signed-off-by: Guoniu.zhou guoniu.zhou@nxp.com Reviewed-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 Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@8ca5df3d

[PATCH] media: ov5640: Fix analogue gain control

[ Upstream commit afa4805799c1d332980ad23339fdb07b5e0cf7e0 ]

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: Laurent Pinchart laurent.pinchart@ideasonboard.com Reviewed-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Reviewed-by: Jai Luthra j-luthra@ti.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@aa8f9c82

[PATCH] media: ov5640: Handle delays when no reset_gpio set

[ Upstream commit d7ff69139908842adf824be4f50c7e9ac5886c04 ]

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: 19a81c1426c1 ("[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: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@a20a8616

[PATCH] media: ov5640: Fix soft reset sequence and timings

[ Upstream commit decea0a98b7ac04536c7d659f74783e8d67a06c0 ]

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: 19a81c1426c1 ("[media] add Omnivision OV5640 sensor driver") Reported-by: Nishanth Menon nm@ti.com Suggested-by: Jacopo Mondi jacopo.mondi@ideasonboard.com Signed-off-by: Jai Luthra j-luthra@ti.com Reviewed-by: Jacopo Mondi jacopo.mondi@ideasonaboard.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@c1476660

[PATCH] media: ov5640: set correct default link frequency

[ Upstream commit d7b41196927ba2a2b5badad1a85f9087eb90b076 ]

current_link_freq field in ov5640_dev structure is link frequency, not link frequency array index, so correct it.

Fixes: 3c28588f35d3 ("media: ov5640: Update pixel_rate and link_freq") Signed-off-by: Guoniu.zhou guoniu.zhou@nxp.com Acked-by: Jacopo Mondi jacopo@jmondi.org Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@db31fea5

[PATCH] media: ov5640: Use runtime PM

Switch to using runtime PM for power management. Make it optional, however, to support ACPI.

Signed-off-by: Paul Elder paul.elder@ideasonboard.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@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@b5df23f8

[PATCH] media: ov5640: Move format mux config in format

The image format produced by the sensor is controlled by two registers, whose values computation is open coded in ov5640_set_framefmt().

As we have a list of formats already, move the OV5640_REG_FORMAT_CONTROL00 and OV5640_REG_ISP_FORMAT_MUX_CTRL register values to the static list of formats instead of open coding it.

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

Commit: clea-os/bsp/rockchip/linux-seco-rk@b89e0963

[PATCH] media: ov5640: Split DVP and CSI-2 formats

The format enumeration list is shared between CSI-2 and DVP modes. This lead to the enumeration of unsupported format variants in both modes.

Separate the list of DVP and CSI-2 formats and create helpers to access the correct one.

Commit: clea-os/bsp/rockchip/linux-seco-rk@5f579552

[PATCH] media: ov5640: Adjust format to bpp in s_fmt

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@982a4717

[PATCH] media: ov5640: Restrict sizes to mbus code

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@0ed80912

[PATCH] media: ov5640: Add BGR888 format

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@42ba2856

[PATCH] media: ov5640: Add RGB565_1X16 format

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@43dfddc2

[PATCH] media: ov5640: Register device properties

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@6ddf979b

[PATCH] media: ov5640: Implement get_selection

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@0925ee68

[PATCH] media: ov5640: Implement init_cfg

Implement the init_cfg pad operation to initialize the subdev state format to the default one.

Commit: clea-os/bsp/rockchip/linux-seco-rk@13ceca78

[PATCH] media: ov5640: Change CSI-2 timings to comply with FPS

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@22a3af17

[PATCH] media: ov5640: Remove frame rate check from find_mode()

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: Jacopo Mondi jacopo@jmondi.org Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@f949c5e9

[PATCH] media: ov5640: Adjust vblank with s_frame_interval

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 jacopo@jmondi.org Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@69a357ea

[PATCH] media: ov5640: Add VBLANK control

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@e680682d

[PATCH] media: ov5640: Add HBLANK control

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@e4f147d0

[PATCH] media: ov5640: Remove ov5640_mode_init_data

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@52143027

[PATCH] media: ov5640: Remove duplicated mode settings

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@14b1cf22

[PATCH] media: ov5640: Re-sort per-mode register tables

The per-mode register tables are not sorted by size. Fix it.

Cosmetic change only.

Commit: clea-os/bsp/rockchip/linux-seco-rk@cf52c2e0

[PATCH] media: ov5640: Provide timings accessor

Provide a function to shortcut access to the correct timings definition to avoid repeating the same pattern when accessing the sensor timings.

Commit: clea-os/bsp/rockchip/linux-seco-rk@d74ca7d0

[PATCH] media: ov5640: Split DVP and CSI-2 timings

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 jacopo@jmondi.org Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@6a13600f

[PATCH] media: ov5640: Fix 720x480 in RGB888 mode

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@5b5df412

[PATCH] media: ov5640: Rework timings programming

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@f31ae5f4

[PATCH] media: ov5640: Rework CSI-2 clock tree

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 jacopo@jmondi.org Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Hugues Fruchet hugues.fruchet@st.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@9d2f2629

[PATCH] media: ov5640: Update pixel_rate and link_freq

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]

Commit: clea-os/bsp/rockchip/linux-seco-rk@1895927b

[PATCH] media: ov5640: Add LINK_FREQ control

Add the V4L2_CID_LINK_FREQ control to the ov5640 driver. Make the control read-only for the moment.

Commit: clea-os/bsp/rockchip/linux-seco-rk@e6c5ca7a

[PATCH] media: ov5640: Associate bpp with formats

Associate the bit depth to each format supported by the sensor.

The bpp will be used to calculate the line length.

Commit: clea-os/bsp/rockchip/linux-seco-rk@0fbf0a88

[PATCH] media: ov5640: Add ov5640_is_csi2() function

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.

Commit: clea-os/bsp/rockchip/linux-seco-rk@36482244

[PATCH] media: ov5604: Re-arrange modes definition

The array of supported modes is close to unreadable. Re-arrange it giving it some room to breath.

Cosmetic change only.

Commit: clea-os/bsp/rockchip/linux-seco-rk@8d1586cf

[PATCH] media: ov5640: Add pixel rate to modes

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: Jacopo Mondi jacopo@jmondi.org Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Tested-by: Adam Ford aford173@gmail.com #imx8mm-beacon-kit Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@80885691

[PATCH] media: ov5640: Fix set format, v4l2_mbus_pixelcode not updated

In ov5640_set_fmt, pending_fmt_change will always be false, because the sensor format is saved before comparing it with the previous format: fmt = &sensor->fmt;... *fmt = *mbus_fmt;... if (mbus_fmt->code != sensor->fmt.code) sensor->pending_fmt_change = true; This causes the sensor to capture with the previous pixelcode.

Also, changes might happen even for V4L2_SUBDEV_FORMAT_TRY, so fix that.

Basically, revert back to the state before commit 071154499193 ("media: ov5640: Fix set format regression") as it was more clear, and then update format even when pixelcode does not change, as resolution might change.

Fixes: 071154499193 ("media: ov5640: Fix set format regression") Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame interval is unchanged") Fixes: fb98e29ff1ea5 ("media: ov5640: fix mode change regression")

Signed-off-by: Mirela Rabulea mirela.rabulea@nxp.com Reviewed-by: Jacopo Mondi jacopo+renesas@jmondi.org Acked-by: Hugues Fruchet hugues.fruchet@st.com Tested-by: Hugues Fruchet hugues.fruchet@st.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com

Commit: clea-os/bsp/rockchip/linux-seco-rk@31daaeb5

[PATCH] media: ov5640: Complement yuv mbus formats with their 1X16 versions

According to media bus pixel codes definition, data formats on serial busses should be described with one bus sample per pixel.

Documentation/userspace-api/media/v4l/subdev-formats.rst states:

"The media bus pixel codes document parallel formats. Should the pixel data be transported over a serial bus, the media bus pixel code that describes a parallel format that transfers a sample on a single clock cycle is used. For instance, both MEDIA_BUS_FMT_BGR888_1X24 and MEDIA_BUS_FMT_BGR888_3X8 are used on parallel busses for transferring an 8 bits per sample BGR data, whereas on serial busses the data in this format is only referred to using MEDIA_BUS_FMT_BGR888_1X24. This is because there is effectively only a single way to transport that format on the serial busses."

Some MIPI CSI receivers strictly obey this definition and declare support for only 1X_ formats.

Hence, complement the supported media bus formats with their 1X16 versions (currently applicable to yuyv, uyvy) to enhance interoperability with CSI receivers.

Signed-off-by: Xavier Roumegue xavier.roumegue@oss.nxp.com Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab+huawei@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@0b6ccb09

[PATCH] media: ov5640: add support of 160x120 resolution

Add support of 160x120 resolution.

Signed-off-by: Hugues Fruchet hugues.fruchet@st.com Tested-by: Jacopo Mondi jacopo+renesas@jmondi.org Signed-off-by: Sakari Ailus sakari.ailus@linux.intel.com Signed-off-by: Mauro Carvalho Chehab mchehab+huawei@kernel.org

Commit: clea-os/bsp/rockchip/linux-seco-rk@a0c0204c

[FIX-PATCH] media: i2c: ov5640: temporary update driver code to apply the next patches

This allows to apply the patches from kernel 6.1 This patch will be reverted once the patches from kernel 6.1 are applied

Commit: clea-os/bsp/rockchip/linux-seco-rk@2a0e9816

[E09][DT] add support for CSI cameras

add support for 2x dual-lane MIPI CSI cameras on connectors J80/J81
with this configuration only one camera at time can work (applying only one dtbo at time)

Commit: clea-os/bsp/rockchip/linux-seco-rk@16ee3964

[E09][DTS] move si5351a clock generator from overlay to main dts

Move the si5351a clock generator from the LVDS overlay to the main dts file since it's shared with the CSI cameras

Commit: clea-os/bsp/rockchip/linux-seco-rk@37243c0b

[DEFCONFIG] add support for ov5640 camera

Enable driver for OV5640 MIPI CSI-2 camera

Integrate meta-seco-rk/linux-seco-rk/niccolor/e09-csi-cameras-ov5640

Merge request reports