Re: dtschema: i2c: messy situation about timeouts

[Wolfram Sang <wsa@kernel.org>]

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


> > > - "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.

To sum it up: a binding defining the maximum time for clock stretching
makes sense in theory. I am currently not aware of a controller where
this could be used (but I surely don't know them all). Most of them keep
SCL low as long as they are busy internally. Not tweakable. So, we defer
this until there is a usecase.

If we ever add it, the above name of the binding cannot be used anymore
because i2c-mpc used it with a different purpose. Not so bad IMO because
"scl-clk" is a pleonasm anyway. I'd suggest "i2c-scl-max-stretch-us" but
am open for suggestions then.

This one can just be deprecated, I'd say.

Happy hacking!


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