Re: [PATCH 2/2] i2c: qcom-cci: Suspend the controller 50 ms after the last transfer

[Birk Skyum]

On Wed, Oct 21, 2026 at 9:44 AM Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx> wrote:
> So, no, we should not rely on runtime suspend/resume timing as a
> workaround for this. That approach is inherently bad and fragile.

Agreed, I'll drop this patch.

> Have you been able to probe the CCI I2C bus during resume? It would be
> useful to see whether there is any activity on SCL/SDA and, in
> particular, whether either line is being held low.

I don't have a scope on these pins, so I read the pad levels from the
TLMM (gpio235/236, aon_cci) in the driver, on 7.3 without this series
and with SCL stretching on (MISC_CTL 0x133):

- When the controller suspends after the sensor powered off, both
  lines read low (13 of 13). The unpowered OV02C10 clamps them.
- At the first transfer after the sensor powered on again, both read
  high (114 of 114).
- At the 100 ms queue timeout both still read high (86 of 86), with the
  queue on its first command (CUR_CMD 0x08010339, CUR_WORD_CNT 1,
  EXEC_WORD_CNT 3, REPORT_STATUS 0) and IRQ_STATUS_0 at 0.
- After cci_reset() the next transfers go through.

So nothing holds SCL or SDA low when the transfer should start. The
master doesn't start until it is reset.

> I wonder if enabling SCL stretching support could help here.

It doesn't change it. Restarting the camera after pauses of 0.05, 0.1,
0.2 and 0.5 s failed in 19 of 20 cycles each with 7.3 as released, and
the same with Hitesh's change applied. After 1 s pauses it was 13 of 20
without it and 15 of 20 with it.

What works without depending on the autosuspend delay is retrying a
message once when it times out, since cci_run_queue() has reset the
controller by then. With that retry in cci_xfer(), the reset on resume
and the 1 s autosuspend unchanged, all 120 camera restarts started
(pauses of 0.05 to 2 s, 20 each). 91 of them hit the stall, and every
retry went through. The cost is the 100 ms timeout, so a restart took
about 500 ms instead of about 400 ms with this patch.

Unless you'd rather see it handled elsewhere, v2 replaces this patch
with that retry.