Re: dtschema: i2c: messy situation about timeouts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> > > - "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: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux