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