AI Camera (IMX500) RP2040 GPIO bridge becomes unresponsive after ~20-25 power cycles, requires host reboot

[LeoMESysteme]

Describe the bug

The RP2040 GPIO bridge chip on the Raspberry Pi AI Camera (IMX500) stops
responding to I2C after roughly 20-25 camera open/close cycles within a
single boot session. Once it happens, every subsequent camera access fails
identically, and only a full host reboot recovers it (a sudo reboot, not
just a driver unbind/rebind of the sensor — untested whether unbind/rebind
of the bridge chip itself recovers it, see below).

Steps to reproduce

Minimal reproducer, no application code involved beyond Picamera2 itself:

from picamera2 import Picamera2
picam2 = Picamera2()
picam2.configure(picam2.create_preview_configuration(main={"size": (960, 720)}))
picam2.start()
picam2.capture_array()
picam2.stop()
picam2.close()

Run this in a loop (we used ~12s between iterations). On a fresh reboot:

• Cycles 1-24 completed cleanly every time (spanning several minutes,
  multiple resolutions/timings tested).
• Cycle 25 failed and every attempt since has failed identically, until the
  next reboot.

Kernel log at the moment of failure

rp2040-gpio-bridge 10-0040: rp2040_gbdg_i2c_send() rp2040_gbdg_wait_until_free failed
rp2040-gpio-bridge 10-0040: rp2040_gbdg_gpio_dir_out(19, 0) could not ST_CL
rp2040-gpio-bridge 10-0040: rp2040_gbdg_i2c_send() rp2040_gbdg_wait_until_free failed
imx500 10-001a: setup of GPIO led failed: -121
imx500 10-001a: imx500_power_on: failed to get led gpio
rp1-cfe 1f00110000.csi: stream on failed in subdev

Followed shortly after by the well-known secondary symptom:

videobuf2_common: driver bug: stop_streaming operation is leaving buffer 0 in active state
WARNING: ... at drivers/media/common/videobuf2/videobuf2-core.c:2215 __vb2_queue_cancel+...

System

• Raspberry Pi 5, AI Camera (IMX500) on CAM/DISP0
• uname -r: 6.12.34+rpt-rpi-2712
• libcamera0.7/libcamera-v4l2: 0.7.2+rpt20260817-1
• libpisp1: 1.7.0-1
• python3-picamera2: 0.3.37-1
• RP2040 bridge firmware: fw ver. 15 (per rp2040_gbdg_probe() log line -
  matches the latest version referenced in the official RP2040 firmware
  update instructions, so this isn't an outdated-firmware problem)

What we've checked so far

• Not a resource-contention issue with other I2C/GPIO consumers on the same
  board (tested with all other periodic I2C/GPIO-using services on the
  system stopped - same result).
• Not fixed by the RP2040 firmware already being current (v15).
• Compared drivers/spi/spi-rp2040-gpio-bridge.ko between our running
  kernel (6.12.34, built 2025-06-26) and an already-installed-but-unbooted
  newer kernel (6.18.34, built 2026-06-09): the rp2040_gbdg_wait_until_free failed code path is byte-identical in both builds, and the driver's
  commit history (8917d44422, 5c1a0c01ce) shows only the initial driver
  and one unrelated MAX_TRANSFER_SIZE increase - nothing addressing this.
• cam0_reg (the shared regulator powering both the IMX500 sensor and the
  RP2040 bridge, GPIO-backed via RP1) still shows num_users: 1, state: enabled while wedged - the physical rail is not being fully
  cycled by normal Picamera2 stop/start alone, since the bridge driver's
  own reference keeps it continuously enabled independent of streaming.

Question / request

Is this a known failure mode? Is there a supported way to recover the RP2040
bridge (e.g., unbind+rebind the 10-0040 i2c device, which should drop
cam0_reg's use count to 0 and force a real power-cycle) without a full
host reboot? Happy to test and report back if there's a suggested
procedure.

[LeoMESysteme]

Update: tested whether unbind/rebind of the rp2040-gpio-bridge i2c device (10-0040) can recover the camera without a full host reboot, on the theory that it shares its power regulator (cam0_reg, GPIO-backed, confirmed via devicetree + live gpiod state) with the imx500 sensor and might force a real power-cycle.

Result: it makes things worse, not better.

• echo 10-0040 > .../rp2040-gpio-bridge/unbind did drop the regulator to num_users: 0 / disabled as expected.
• echo 10-0040 > .../rp2040-gpio-bridge/bind then failed:

  i2c_designware 1f00088000.i2c: controller timed out
  i2c_designware 1f00088000.i2c: i2c_dw_handle_tx_abort: SDA stuck at low
  rp2040-gpio-bridge 10-0040: Could not get device info
  rp2040-gpio-bridge 10-0040: probe with driver rp2040-gpio-bridge failed with error -110
  

• After this, the camera isn't just wedged anymore — it's not detected at all (No camera number 0 found, where before it was at least enumerated).

So: no working no-reboot recovery found. If anything, this suggests the regulator toggle needs the bridge's own i2c bus recovery/init sequence to happen in a specific order/timing that a bare unbind/bind doesn't provide, or the RP2040 needs longer than our ~2s off-window to come back cleanly on I2C. Recommend against naive unbind/rebind as a workaround until/unless someone with visibility into the RP2040 firmware and the driver's probe() sequencing weighs in. Rebooting now to recover.

[LeoMESysteme]

Additional finding on the follow-up above: the I2C bus this all happens on (`i2c@88000`, RP1, the one carrying both `imx500@1a` and `spi@40`/rp2040-gpio-bridge) has no `scl-gpios`/`sda-gpios` properties in its devicetree node - only `clock-frequency`, `i2c-scl-falling-time-ns`, `i2c-scl-rising-time-ns`, `pinctrl-0`, etc.

That means Linux's standard built-in generic GPIO bus-recovery mechanism (`i2c_generic_gpio_recovery`, used by many other i2c-designware instances precisely for a stuck-SDA condition) isn't wired up for this bus at all. When SDA got stuck low in my unbind/rebind test above, there was no automatic in-kernel recovery path available - it just stayed stuck until reboot.

If the RP1's pinmux allows SCL/SDA to be re-muxed as plain GPIOs during a recovery cycle (which is what this binding needs), adding `scl-gpios`/`sda-gpios` to this node in the base devicetree (or a downstream overlay) could let the kernel automatically clear this exact lockup on its own, without any host reboot - independent of whatever the actual root cause of the RP2040 becoming unresponsive turns out to be. Might be worth someone with visibility into the RP1 pinmux checking whether this is feasible for this specific bus.

[LeoMESysteme]

Further update: tried two more variations, both with root access, one including a genuine physical disconnect/reconnect of the camera's CSI ribbon cable (not just a software power toggle) - all three attempts now fail identically:

1. unbind/rebind of just the bridge (10-0040), 2s off-window: SDA stuck at low, camera not detected afterward.
2. unbind/rebind of both bridge and sensor (10-0040 + 10-001a), 20s off-window: i2c_designware ... controller timed out -> rp2040-gpio-bridge ... probe failed with error -110, camera not detected afterward.
3. Physically unplugged and reseated the CSI ribbon cable (genuine electrical disconnect, not a software toggle), then attempted the same bind sequence: identical result to (2) - controller timed out / probe failed with -110.

The fact that a real physical cable disconnect doesn't change the outcome at all is the important new data point: it means the camera module itself isn't the thing holding the bus - the host-side i2c-designware controller (RP1's I2C peripheral, 1f00088000.i2c) is the one stuck, independent of whether the camera module is even electrically present. That's consistent with my earlier finding that this bus has no scl-gpios/sda-gpios configured for Linux's generic bus-recovery mechanism - once the controller itself is in this state, nothing short of resetting the controller (a full host reboot) clears it.

So: no working no-reboot recovery found after three independent attempts, including one that rules out the camera module as the persistently-stuck component. If anyone can point to a supported way to reset just this i2c-designware instance's hardware state without a full reboot (module reload of i2c_designware_platform? some register-level reset the driver doesn't expose?), that would be the thing to try next - we don't have visibility into that from userspace.

[naushir]

I've attempted to reproduce your issue with the given picamera2 script. Unfortunately I've not been able to with an identical S/W environment from what you have listed. Is there anything more that you may be doing to provoke the bug? Perhaps some changes in /boot/firmware/config.txt?

[naushir]

IF you are able to, please build and test with the following kernel tree:
https://github.com/naushir/linux/tree/imx500_tests

They have some speculative fixes + a real PM runtime fix that may help with your issue.