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

[Frank Li]

On Thu, May 21, 2026 at 07:49:52PM +0800, Robby Cai wrote:
> On Wed, May 20, 2026 at 02:52:24PM -0400, Frank Li wrote:
> > 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.
>
> okay, I'll try to switch to use this approach in next revision.
>
> Some devices require coordinated RESET and PWDN sequencing, but in this
> case the device can be properly initialized with RESET held inactive and
> controlled solely via the PWDN signal, which makes this approach viable.

PWDN should go through regulator interface.

>
> >
> > >
> > > 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.
>
>
> Just to clarify, the reset GPIO in this design is provided by the SoC GPIO
> controller (gpio1), not an external I2C GPIO expander.

It is just special case. you touch ov5640 driver code, so need consider
more general case.

Frank
>
> Therefore, the "late reset" issue you mentioned does not apply here.
>
> Regards,
> Robby
> >
> > 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
> > >