Re: [PATCH RFC 4/7] i3c: add driver for Renesas I3C IP

Wolfram Sang
2025-07-24T10:04:01Z

> > + renesas_i3c_enqueue_xfer(i3c, xfer);
> > + if (!wait_for_completion_timeout(&xfer->comp, XFER_TIMEOUT))
> > + renesas_i3c_dequeue_xfer(i3c, xfer);
>
> This may common problem, I3C spec have 100us timeout, target side may
> timeout when driver wait for irq. So target side treat "repeat start" as
> "start" and issue address arbitration.

Looking more at this issue, I think these are two separate problems.
Chapter 5.1.2.5 mandates that the controller shall not hold SCL low for
more than 100us in most situations and by no means longer than 15ms in
any situation.

Depending on the controller, this may be need to be handled in software.
Or it may be handled in hardware which could raise an exception and
release SCL on its own if the timing was violated.

The above completion is for the *whole transfer*, though, including the
target response time. Like I2C, it is not specified for I3C. At least, I
couldn't find it and I recall no one at the I3C plugfest could point me
to one as well.

So, this completion timeout is more than just 5.1.2.5. It might make
sense to investigate a more reasonable value. But I don't think this
should be imposed on someone submitting a new driver. It is a dedicated
task. And I am not even sure the result will be a subsystem-wide static
value. It might be a calculated value. Maybe even a driver-specific
calculated value.

So, I think the best we can do until we have this investigation is to
keep drivers consistent with the historically grown value.

Or?