Re: dtschema: i2c: messy situation about timeouts

[Wolfram Sang <wsa@kernel.org>]

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

Hi Andi,

> > - "i2c-scl-has-clk-low-timeout"
> > 
> > AFAIU this binding tells that the controller can do clock stretching.
> > But what for?
> 
> One of the controllers that was sent a while back required some
> hardware description because, in some versions, clock stretching
> was supported in the hardware.

I see. Still, I think this can (and should be handled) with
I2C_AQ_NO_CLK_STRETCH.

> The naming is a bit fancy, but it depends on the specification
> used as a reference; SMBus, I2C, or specific drivers often refer
> to it differently.

Yes. I'd give I2C specs most importance, controller documentation least.
And probably a salt of personal preference :)

> > - "i2c-scl-clk-low-timeout-us"
> > 
> > The description says "Number of microseconds the clock line needs to be
> > pulled down in order to force a waiting state." What does "forcing a
> > waiting state" mean here? I don't understand this description.
> 
> It comes from the specification. The clock stretching is given as
> an interval that can be tweaked depending on the hardware.

You mean the maximum clock stretching is tweakable? That, in deed, could
be a binding in the future, in theory. Yet, it would need support in the
client drivers. Like a touchscreen driver which assumes a reset after a
certain time of inactivity.

> So far I haven't seen anyone using it, though.

The MPC driver used it, just for a different purpose.  It was used for a
timeout of the total transfer. That's a different thing. So, I suggested
the conversion.

Happy hacking,

   Wolfram


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