Re: dtschema: i2c: messy situation about timeouts

Wolfram Sang <[email protected]> Tue, 27 Feb 2024 13:57:52 +0100

Newsgroups	org.kernel.vger.devicetree-spec,org.kernel.vger.linux-i2c
Message-ID	<Zd3cUKCHnn9n57pD@shikoro>

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

signature.asc (application/pgp-signature, 833 B)