[PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[Robby Cai]

Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
on the i.MX8MQ EVK, and add two OV5640 camera sensors.

The sensors are connected via I2C1 and I2C2, each with proper
endpoint descriptions to form complete media pipelines.

The resulting pipelines are:

  - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
  - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge

Both pipelines have been validated on the i.MX8MQ EVK using the
upstream OV5640 driver.

Both OV5640 sensors share a single reset GPIO on this board,
which prevents independent hardware reset when both cameras
are enabled. As a result, the reset line is kept deasserted
via a GPIO hog, and sensor reset is performed via software.

This reflects a hardware limitation of the i.MX8MQ EVK design,
which does not provide independent reset control for the two
image sensors.

Both sensors also share a single MCLK source (CLKO2). The clock
is configured identically for both devices to match the board
design.

Signed-off-by: Robby Cai <robby.cai@nxp.com>
---

Changes in v2:
- Address comments on MIPI clock configuration (Frank, Sebastian):
  drop the first patch and consolidate the correct clock configuration
  into the second patch
- Address comments from sashiko:
  * Use MEDIA_BUS_TYPE_CSI2_DPHY instead of a literal value
  * Fix a probe-order dependency related to reset handling. Switch to
    software reset, as the shared hardware reset line prevents
    independent reset when both cameras are enabled due to a board
    design limitation
  * Fix incorrect voltage value in the reg_2v8 node

Link to v1: https://lore.kernel.org/imx/20260417110200.753678-1-robby.cai@nxp.com/



Note:
This patch relies on commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly release reset")
and patch [1]. These two changes are interdependent and must be
applied together for correct behavior. Applying only one of them
is insufficient and may result in incorrect operation.

[1] https://lore.kernel.org/imx/20260417080851.489303-1-robby.cai@nxp.com/



Validated with following commands:

On CSI1:

media-ctl -d 0 -l "'ov5640 1-003c':0 -> 'imx8mq-mipi-csi2 30a70000.csi':0 [1]"
media-ctl -d 0 -V "'ov5640 1-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'imx8mq-mipi-csi2 30a70000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap

On CSI2:

media-ctl -d 1 -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 30b60000.csi':0 [1]"
media-ctl -d 1 -V "'ov5640 0-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'imx8mq-mipi-csi2 30b60000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 1 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap


---
 arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 165 +++++++++++++++++++
 1 file changed, 165 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index d48f901487d4..2311a05b88c5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -6,6 +6,8 @@
 
 /dts-v1/;
 
+#include <dt-bindings/media/video-interfaces.h>
+
 #include "imx8mq.dtsi"
 
 / {
@@ -50,6 +52,20 @@ reg_usdhc2_vmmc: regulator-vsd-3v3 {
 		enable-active-high;
 	};
 
+	reg_1v5: regulator-1v5 {
+		compatible = "regulator-fixed";
+		regulator-name = "DVDD_1V5";
+		regulator-min-microvolt = <1500000>;
+		regulator-max-microvolt = <1500000>;
+	};
+
+	reg_2v8: regulator-2v8 {
+		compatible = "regulator-fixed";
+		regulator-name = "AVDD_2V8";
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+	};
+
 	buck2_reg: regulator-buck2 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_buck2>;
@@ -172,6 +188,14 @@ &A53_3 {
 	cpu-supply = <&buck2_reg>;
 };
 
+&csi1 {
+	status = "okay";
+};
+
+&csi2 {
+	status = "okay";
+};
+
 &ddrc {
 	operating-points-v2 = <&ddrc_opp_table>;
 	status = "okay";
@@ -230,6 +254,19 @@ vddh: vddh-regulator {
 	};
 };
 
+&gpio1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_camera_reset>;
+
+	/* deasserted: logical 0 -> physical 1 via ACTIVE_LOW */
+	camera-reset-hog {
+		gpio-hog;
+		gpios = <6 GPIO_ACTIVE_LOW>;
+		output-low;
+		line-name = "camera-reset";
+	};
+};
+
 &gpio5 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_wifi_reset>;
@@ -330,12 +367,101 @@ vgen6_reg: vgen6 {
 			};
 		};
 	};
+
+	camera@3c {
+		compatible = "ovti,ov5640";
+		reg = <0x3c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_camera2_pwdn>;
+		clocks = <&clk IMX8MQ_CLK_CLKO2>;
+		clock-names = "xclk";
+		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+		assigned-clock-rates = <20000000>;
+		powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+		DOVDD-supply = <&sw4_reg>;
+		AVDD-supply = <&reg_2v8>;
+		DVDD-supply = <&reg_1v5>;
+
+		port {
+			camera2_ep: endpoint {
+				remote-endpoint = <&mipi_csi2_in_ep>;
+				clock-lanes = <0>;
+				data-lanes = <1 2>;
+			};
+		};
+	};
+};
+
+&i2c2 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_i2c2>;
+	status = "okay";
+
+	camera@3c {
+		compatible = "ovti,ov5640";
+		reg = <0x3c>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_camera1_pwdn>;
+		clocks = <&clk IMX8MQ_CLK_CLKO2>;
+		clock-names = "xclk";
+		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+		assigned-clock-rates = <20000000>;
+		powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+		DOVDD-supply = <&sw4_reg>;
+		AVDD-supply = <&reg_2v8>;
+		DVDD-supply = <&reg_1v5>;
+
+		port {
+			camera1_ep: endpoint {
+				remote-endpoint = <&mipi_csi1_in_ep>;
+				clock-lanes = <0>;
+				data-lanes = <1 2>;
+			};
+		};
+	};
 };
 
 &lcdif {
 	status = "okay";
 };
 
+&mipi_csi1 {
+	assigned-clock-rates = <266000000>, <200000000>, <66000000>;
+	status = "okay";
+
+	ports {
+		port@0 {
+			reg = <0>;
+
+			mipi_csi1_in_ep: endpoint {
+				remote-endpoint = <&camera1_ep>;
+				data-lanes = <1 2>;
+				bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+			};
+		};
+	};
+};
+
+&mipi_csi2 {
+	assigned-clock-rates = <266000000>, <200000000>, <66000000>;
+	status = "okay";
+
+	ports {
+		port@0 {
+			reg = <0>;
+
+			mipi_csi2_in_ep: endpoint {
+				remote-endpoint = <&camera2_ep>;
+				data-lanes = <1 2>;
+				bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+			};
+		};
+	};
+};
+
 &mipi_dsi {
 	#address-cells = <1>;
 	#size-cells = <0>;
@@ -532,12 +658,37 @@ &wdog1 {
 };
 
 &iomuxc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_mclk>;
+
 	pinctrl_buck2: vddarmgrp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13		0x19
 		>;
 	};
 
+	pinctrl_camera1_pwdn: camera1pwdngrp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3		0x19
+		>;
+	};
+
+	pinctrl_camera2_pwdn: camera2pwdngrp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5		0x19
+		>;
+	};
+
+	/*
+	 * Shared reset line for cameras on CSI1 and CSI2.
+	 * Configured as GPIO and held high; sensors rely on software reset.
+	 */
+	pinctrl_camera_reset: cameraresetgrp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6		0x19
+		>;
+	};
+
 	pinctrl_fec1: fec1grp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC			0x3
@@ -565,12 +716,26 @@ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA			0x4000007f
 		>;
 	};
 
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL			0x4000007f
+			MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA			0x4000007f
+		>;
+	};
+
 	pinctrl_ir: irgrp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12		0x4f
 		>;
 	};
 
+	/* Shared MCLK for cameras on CSI1 and CSI2. */
+	pinctrl_mclk: mclkgrp {
+		fsl,pins = <
+			MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2	0x59
+		>;
+	};
+
 	pinctrl_mipi_dsi: mipidsigrp {
 		fsl,pins = <
 			MX8MQ_IOMUXC_ECSPI1_SCLK_GPIO5_IO6		0x16
-- 
2.37.1

Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The proposed device tree configuration intends to use software reset by omitting `reset-gpios`, but the upstream OV5640 driver skips the software reset sequence if `powerdown-gpios` is present.
--

commit d18d0c4c95f98f3312c777b828bf09c413169ce3
Author: Robby Cai <robby.cai@nxp.com>

arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
on the i.MX8MQ EVK, and add two OV5640 camera sensors.

> Both OV5640 sensors share a single reset GPIO on this board,
> which prevents independent hardware reset when both cameras
> are enabled. As a result, the reset line is kept deasserted
> via a GPIO hog, and sensor reset is performed via software.

Will the software reset actually occur if powerdown-gpios is provided?

Looking at the ov5640 driver's power up sequence, the software reset is
skipped if the powerdown gpio is present:

drivers/media/i2c/ov5640.c:ov5640_powerup_sequence() {
	if (sensor->pwdn_gpio) {
		gpiod_set_value_cansleep(sensor->reset_gpio, 1);
		...
		gpiod_set_value_cansleep(sensor->reset_gpio, 0);
	} else {
		/* software reset */
		ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0,
				 OV5640_REG_SYS_CTRL0_SW_RST);
		...
	}
}

Since the device tree nodes define powerdown-gpios, does this mean the
driver will skip the software reset branch entirely?

> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> index d48f901487d49..2311a05b88c50 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts

[ ... ]

> @@ -330,12 +367,101 @@ vgen6_reg: vgen6 {
>  			};
>  		};
>  	};
> +
> +	camera@3c {
> +		compatible = "ovti,ov5640";
> +		reg = <0x3c>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_camera2_pwdn>;
> +		clocks = <&clk IMX8MQ_CLK_CLKO2>;
> +		clock-names = "xclk";
> +		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
> +		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
> +		assigned-clock-rates = <20000000>;
> +		powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;

Since the reset gpio is omitted here and is kept deasserted by a hog
elsewhere, does providing powerdown-gpios result in both hardware
and software resets being bypassed?

> +		DOVDD-supply = <&sw4_reg>;
> +		AVDD-supply = <&reg_2v8>;
> +		DVDD-supply = <&reg_1v5>;
> +
> +		port {
> +			camera2_ep: endpoint {
> +				remote-endpoint = <&mipi_csi2_in_ep>;
> +				clock-lanes = <0>;
> +				data-lanes = <1 2>;
> +			};
> +		};
> +	};
> +};
> +
> +&i2c2 {
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_i2c2>;
> +	status = "okay";
> +
> +	camera@3c {
> +		compatible = "ovti,ov5640";
> +		reg = <0x3c>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_camera1_pwdn>;
> +		clocks = <&clk IMX8MQ_CLK_CLKO2>;
> +		clock-names = "xclk";
> +		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
> +		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
> +		assigned-clock-rates = <20000000>;
> +		powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;

Could this regression also prevent initialization on the second camera
for the same reason?

> +		DOVDD-supply = <&sw4_reg>;
> +		AVDD-supply = <&reg_2v8>;
> +		DVDD-supply = <&reg_1v5>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260515111143.2980956-1-robby.cai@nxp.com?part=1

Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[Robby Cai]

On Fri, May 15, 2026 at 11:33:17AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The proposed device tree configuration intends to use software reset by omitting `reset-gpios`, but the upstream OV5640 driver skips the software reset sequence if `powerdown-gpios` is present.
> --
> 
> commit d18d0c4c95f98f3312c777b828bf09c413169ce3
> Author: Robby Cai <robby.cai@nxp.com>
> 
> arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
> 
> Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> 
> > Both OV5640 sensors share a single reset GPIO on this board,
> > which prevents independent hardware reset when both cameras
> > are enabled. As a result, the reset line is kept deasserted
> > via a GPIO hog, and sensor reset is performed via software.
> 
> Will the software reset actually occur if powerdown-gpios is provided?
> 
> Looking at the ov5640 driver's power up sequence, the software reset is
> skipped if the powerdown gpio is present:
> 
> drivers/media/i2c/ov5640.c:ov5640_powerup_sequence() {
> 	if (sensor->pwdn_gpio) {
> 		gpiod_set_value_cansleep(sensor->reset_gpio, 1);
> 		...
> 		gpiod_set_value_cansleep(sensor->reset_gpio, 0);
> 	} else {
> 		/* software reset */
> 		ov5640_write_reg(sensor, OV5640_REG_SYS_CTRL0,
> 				 OV5640_REG_SYS_CTRL0_SW_RST);
> 		...
> 	}
> }
> 
> Since the device tree nodes define powerdown-gpios, does this mean the
> driver will skip the software reset branch entirely?
> 

Yes, that's correct.

When `powerdown-gpios` is present, the OV5640 driver follows the
PWDN-controlled power cycle path and skips the explicit software reset.

This is intentional for this board, where both sensors share a single
reset line and cannot be reset independently. To avoid interference,
the reset line is kept deasserted (via a GPIO hog), and initialization
relies on the powerdown GPIO and power cycling instead.

This matches setups described in the driver where a single control
signal effectively drives both reset and power sequencing (e.g. PWUP-
style designs), making a separate software reset unnecessary. [1]

Additionally, using the powerdown path preserves the intended hardware
integration: PWDN is the only per-device control signal, while reset
is shared. This allows independent control of each sensor and avoids
introducing artificial dependencies on the shared reset line.

For these reasons, the design intentionally relies on powerdown-based
sequencing rather than the software reset path.

I will update the commit message to make this behavior explicit.


[1] https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov5640.c#L2449-L2464

> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > index d48f901487d49..2311a05b88c50 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> 
> [ ... ]
> 
> > @@ -330,12 +367,101 @@ vgen6_reg: vgen6 {
> >  			};
> >  		};
> >  	};
> > +
> > +	camera@3c {
> > +		compatible = "ovti,ov5640";
> > +		reg = <0x3c>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_camera2_pwdn>;
> > +		clocks = <&clk IMX8MQ_CLK_CLKO2>;
> > +		clock-names = "xclk";
> > +		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
> > +		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
> > +		assigned-clock-rates = <20000000>;
> > +		powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> 
> Since the reset gpio is omitted here and is kept deasserted by a hog
> elsewhere, does providing powerdown-gpios result in both hardware
> and software resets being bypassed?

Not exactly.

The software reset is skipped, but the sensor is still reset
via the power-cycle sequence using the PWDN GPIO.

The hardware reset line is intentionally not used since it is
shared between both sensors.

> 
> > +		DOVDD-supply = <&sw4_reg>;
> > +		AVDD-supply = <&reg_2v8>;
> > +		DVDD-supply = <&reg_1v5>;
> > +
> > +		port {
> > +			camera2_ep: endpoint {
> > +				remote-endpoint = <&mipi_csi2_in_ep>;
> > +				clock-lanes = <0>;
> > +				data-lanes = <1 2>;
> > +			};
> > +		};
> > +	};
> > +};
> > +
> > +&i2c2 {
> > +	clock-frequency = <100000>;
> > +	pinctrl-names = "default";
> > +	pinctrl-0 = <&pinctrl_i2c2>;
> > +	status = "okay";
> > +
> > +	camera@3c {
> > +		compatible = "ovti,ov5640";
> > +		reg = <0x3c>;
> > +		pinctrl-names = "default";
> > +		pinctrl-0 = <&pinctrl_camera1_pwdn>;
> > +		clocks = <&clk IMX8MQ_CLK_CLKO2>;
> > +		clock-names = "xclk";
> > +		assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
> > +		assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
> > +		assigned-clock-rates = <20000000>;
> > +		powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
> 
> Could this regression also prevent initialization on the second camera
> for the same reason?
> 

No, it should not.

Each sensor has its own powerdown GPIO, so initialization is handled
independently via the PWDN-controlled power cycle.

The shared reset line is not used, so there is no cross-impact between
the two cameras during initialization.

> > +		DOVDD-supply = <&sw4_reg>;
> > +		AVDD-supply = <&reg_2v8>;
> > +		DVDD-supply = <&reg_1v5>;
> 
> -- 
> Sashiko AI review  https://sashiko.dev/#/patchset/20260515111143.2980956-1-robby.cai@nxp.com?part=1

Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[Frank Li]

On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> on the i.MX8MQ EVK, and add two OV5640 camera sensors.
>
> The sensors are connected via I2C1 and I2C2, each with proper
> endpoint descriptions to form complete media pipelines.
>
> The resulting pipelines are:
>
>   - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
>   - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
>
> Both pipelines have been validated on the i.MX8MQ EVK using the
> upstream OV5640 driver.
>
> Both OV5640 sensors share a single reset GPIO on this board,
> which prevents independent hardware reset when both cameras
> are enabled. As a result, the reset line is kept deasserted
> via a GPIO hog, and sensor reset is performed via software.

Does reset_control_get_shared() resolve this problem?

Frank

Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[Robby Cai]

On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> >
> > The sensors are connected via I2C1 and I2C2, each with proper
> > endpoint descriptions to form complete media pipelines.
> >
> > The resulting pipelines are:
> >
> >   - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> >   - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> >
> > Both pipelines have been validated on the i.MX8MQ EVK using the
> > upstream OV5640 driver.
> >
> > Both OV5640 sensors share a single reset GPIO on this board,
> > which prevents independent hardware reset when both cameras
> > are enabled. As a result, the reset line is kept deasserted
> > via a GPIO hog, and sensor reset is performed via software.
> 
> Does reset_control_get_shared() resolve this problem?
> 

No, reset_control_get_shared() does not really solve this issue.

The problem here is not about software coordination, but about the
hardware topology: both sensors are physically tied to the same reset
line. This means any reset operation will always affect both devices
simultaneously, regardless of how the reset framework is used.

While reset_control_get_shared() introduces reference counting to avoid
unintended assertions, it does not allow independent reset control.
In particular:

  - A reset operation (assert) will still impact both sensors.
  - It does not solve the requirement for per-device hardware reset.

Therefore, using a shared reset control does not provide true isolation
between the two OV5640 instances.

Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
handling initialization through software/power sequencing is a valid
and practical solution for this hardware design.

This matches the intention of the upstream changes as well, where GPIO-
based resets are treated as simple control signals rather than fully
isolated reset domains.

In practice, using a shared reset here can even introduce subtle
interference between the two cameras during probe or power cycling,
so it is safer to avoid using reset for runtime control entirely.

Regards,
Robby

Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras

[Frank Li]

On Wed, May 20, 2026 at 02:54:52PM +0800, Robby Cai wrote:
> On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> > On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> > >
> > > The sensors are connected via I2C1 and I2C2, each with proper
> > > endpoint descriptions to form complete media pipelines.
> > >
> > > The resulting pipelines are:
> > >
> > >   - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> > >   - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> > >
> > > Both pipelines have been validated on the i.MX8MQ EVK using the
> > > upstream OV5640 driver.
> > >
> > > Both OV5640 sensors share a single reset GPIO on this board,
> > > which prevents independent hardware reset when both cameras
> > > are enabled. As a result, the reset line is kept deasserted
> > > via a GPIO hog, and sensor reset is performed via software.
> >
> > Does reset_control_get_shared() resolve this problem?
> >
>
> No, reset_control_get_shared() does not really solve this issue.
>
> The problem here is not about software coordination, but about the
> hardware topology: both sensors are physically tied to the same reset
> line. This means any reset operation will always affect both devices
> simultaneously, regardless of how the reset framework is used.

Reset framework is resolve this problem. It is quite common that many devices
shared one reset pin.

>
> While reset_control_get_shared() introduces reference counting to avoid
> unintended assertions, it does not allow independent reset control.
> In particular:
>
>   - A reset operation (assert) will still impact both sensors.

yes, only when first devices toggle reset signal. Second device do nothing.

>   - It does not solve the requirement for per-device hardware reset.

It is hardware limitation.

>
> Therefore, using a shared reset control does not provide true isolation
> between the two OV5640 instances.

It is not isolation. Just don't allow second device to toggle reset pin.

>
> Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
> handling initialization through software/power sequencing is a valid
> and practical solution for this hardware design.

If use i2c gpio, expandor driver may probe after sensor driver probe. So
reset may happen after sensor driver probe.

Frank
>
> This matches the intention of the upstream changes as well, where GPIO-
> based resets are treated as simple control signals rather than fully
> isolated reset domains.
>
> In practice, using a shared reset here can even introduce subtle
> interference between the two cameras during probe or power cycling,
> so it is safer to avoid using reset for runtime control entirely.
>
> Regards,
> Robby
>