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

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

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.

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

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