On 12/03/21 10:34 am, Guenter Roeck wrote:

On 3/11/21 1:17 PM, Chris Packham wrote:

quoted

On 11/03/21 9:18 pm, Wolfram Sang wrote:

quoted

quoted

Bummer. What is really weird is that you see clock stretching under
CPU load. Normally clock stretching is triggered by the device, not
by the host.

One example: Some hosts need an interrupt per byte to know if they
should send ACK or NACK. If that interrupt is delayed, they stretch the
clock.

It feels like something like that is happening. Looking at the T2080
Reference manual there is an interesting timing diagram (Figure 14-2 if
someone feels like looking it up). It shows SCL low between the ACK for
the address and the data byte. I think if we're delayed in sending the
next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec.

I think that really leaves you only two options that I can see:
Rework the driver to handle critical actions (such as setting TXAK,
and everything else that might result in clock stretching) in the
interrupt handler, or rework the driver to handle everything in
a high priority kernel thread.

I've made some reasonable progress on making i2c-mpc more interrupt 
driven. Assuming it works out for my use-case is there an opinion on 
making interrupt support mandatory? Looking at all the in-tree dts files 
that use one of the compatible strings from i2c-mpc.c they all have 
interrupt properties so in theory nothing is using the polling mode. But 
there may be some out-of-tree boards or boards using an old dtb that 
would be affected?