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:

quoted

On Wed, May 20, 2026 at 02:54:52PM +0800, Robby Cai wrote:

quoted

On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:

quoted

On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:

quoted

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.

quoted

quoted

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.

quoted

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

It is hardware limitation.

quoted

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.

quoted

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

quoted

Frank

quoted

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