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

[Robby Cai <robby.cai@nxp.com>]

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