Re: [PATCH v6 1/2] i2c: core: Add i2c_update_timeout() helper for dynamic transfer timeouts

[Wolfram Sang <wsa+renesas@sang-engineering.com>]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

Hi,

> My thinking was that we are trying to derive a timeout for transfer
> completion, so the transfer length and bus frequency should already give
> us the theoretical on-the-wire transfer time.

With my experience in all these years with I2C, this is exactly true. It
is a _theoretical_ value, and the practical value is at least board(!)
dependant. It may also depend on the environment in other cases. So, the
theoretical value may supply a minimum but IMO this doesn't help.
Because we want a precise value, but we don't know it.

> On top of that, we could add a fixed margin to account for interrupt and
> system scheduling latency before converting the result to jiffies.
> 
> The exact margin is open for discussion. I was considering something on
> the order of a few hundred milliseconds (e.g. 500 ms), but perhaps that
> is still too optimistic on some systems?

See, you simply cannot know. So, why not leaving it to those who do know
for their system?

> Alternatively, the core could provide a calculated baseline timeout
> (transfer time + fixed margin) and allow userspace to add an optional
> extra offset when needed. That way the default behavior remains automatic
> and works for most clients, while systems with unusual latency
> requirements can still increase the timeout without every userspace client
> having to determine an appropriate value itself.

We already have a mechanism for userspace to set a timeout.

> Do you see cases where a transfer-time-based timeout with a generous
> system-latency margin would still be insufficient?

Regressions. You could time out too early on boards which worked before.

Happy hacking,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]