Re: Delay between stop condition and start condition

[Wolfram Sang <wsa@the-dreams.de>]

Hi Fabrizio, everyone,

Thanks for bringing this up!

> What's the best way to address this? I could pull in the HDMI
> transmitter driver the code to read the EDID back from the monitor so
> that I can fit device specific delays without impacting the generic
> implementation of the EDID readback, but that would replicate some
> code and the driver would not benefit from fixes made to the generic
> implementation. I could change the RCar I2C driver in order to fit a
> new DT parameter (i2c-delay-after-stop-us?), and the driver would put
> in the desired delay after every stop condition, but isn't this
> parameter something every I2C controller would benefit from (now that
> we know we have a use case for it)? What are your thoughts and
> recommendations?

No need for a property. The I2C standard has a clearly defined value for
that which is named 'tbuf' and is in general the same value as the
minimal low period of the SCL signal. So, it must be handled at the I2C
bus master level.

Currently, we have no rule at what time drivers have to leave the
master_xfer() callback. Some exit when STOP is still processed, some
when STOP has been sent. I am not aware of a driver respecting tbuf. It
seems worth recommending to respect tbuf.

I think this needs to be completely handled in the bus master driver. We
have USB-to-I2C bridges which we can control only high level and the
firmware of those need to respect tbuf. I don't see how the I2C core
could support individual drivers here.

So, that's how I see this situation. Other comments? Other ideas?

Thanks,

   Wolfram