i2c-algo-bit timing

Mark Studebaker mds at paradyne.com
Tue Dec 10 23:46:10 CET 2002


Kyosti
(sorry, don't know how to make the dots over the o!),

thanks for the notes and the opportunity to make comments.

As I've already said, I like the 50/50 duty cycle, with 
1 ns hold and (udelay - 1) setup. That's the way it should be.

One question - is clock low time == udelay at end of a
read, including end of i2c_inb and i2c_stop? it looks to me like
it's only Tmin + Tmin? 

One other general comment - sdalo() and sdahi() could be deleted
and inlined into test_bus(), which is the only place they're used?

Other comments below.

Kyösti Mälkki wrote:
> 
> On Sun, 1 Dec 2002, Kyösti Mälkki wrote:
> 
> > First, included gzipped patch against latest CVS, it's my current local
> > work I told I would not commit before release and round for comments.
> >
> 
> Some notes to comment on the changes in the patch..
> 
> I have been reading the "Fast Mode" specs to test my setup, at some
> points the 1 us I use violates this.

Disagree. If you think about it, the max hold spec really only applies
when you are an i2c slave. When you are a master and driving the clock,
you can exceed the max hold time since you are essentially
"extending the clock low time" as described in the footnote.
If 1 us > 0.9 us spec is a problem, then we certainly have a
problem now with a hold time == udelay.

> 
> For debug use, we need adapter name from i2c_adapter everywhere.
> Current debugging is useless, while the original was simply
> incomprehensible. Sorry about the misspelling.
> 

Agreed that it wasn't very good in the past.

> Improved symmetry; outb/inb now both handle the acknowledge timeslot.
> Sendbytes/readbytes only loop over the buffer and test for failures.
> Pass i2c_msg->flags deeper down to support more i2c mangling.
> 

Sounds good.

> The i2c_adapter->retry now applies to complete message. Previously
> it would fail on any [NA] after the address [A].
> I am not 100% sure how auto-incrementing EEPs will tolerate it,
> if we fail in the middle of a page and then resend from the beginning.
> 

We may want to think about this more. Or maybe do something different
on reads than on writes. We don't want to corrupt eeproms.

> A message may be sent correctly after ignored [NA], retry or timeout.
> The caller could check this in i2c_msg->err, if necessary.
> 

OK. But the whole mechanism of saving and checking the error, etc. is somewhat elaborate,
not sure if useful or not. If you look at the smbus-layer calls (which in turn use
the "emulation layer" if the adapter is i2c-only), errors aren't returned at all.
Which isn't great but that's the way it is now. In fact we have a two-year-old ticket
(#517 http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=517 )
asking for improvement. I don't have any answers, just wondering if anybody
has a "vision" (!) on error handling and whether the changes in i2c-algo-bit
fit that vision. 

> --
>   Kyösti Mälkki
>   kmalkki at cc.hut.fi



More information about the lm-sensors mailing list