[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
>