[i2c] [patch 2.6.24-rc1-git] i2c-algo-bit, don't yield()
david-b at pacbell.net
Fri Nov 16 19:42:41 CET 2007
On Friday 16 November 2007, Jean Delvare wrote:
> Two more things. First, the good news: with your patch applied,
> "modprobe eeprom" is down from 5.2 s to 1.4 s on my system. That's just
> an example of the performance boost brought by your patch. The
> difference is admittedly magnified by the fact that one of my
> (radeonfb) i2c adapters is broken and all transactions timeout there,
> but the principle still applies to the general case.
Yeah, I noticed it as extra delays responding to SMBALERT# ...
not such large delays, but needless ones nonetheless.
> Second, about the returned error code: we are deleting the retry
> mechanism from bus drivers on the basis that it's a chip-specific
> attribute whether retries make sense or not.
I think you mean a "slave-specific" attribute.. Plus let's not
overlook "mechanism not implemented correctly or uniformly"!
> If so, shouldn't we give
> chip drivers a way to differentiate between a slave not acking its
> address and other transaction errors? I think that i2c-algo-bit (and
> other bus drivers) should return a unique error code (-ENODEV?) for the
> former case. What do you think?
Not that error codes are reliably passed up through the stack yet,
even starting at the lowest levels ... ;)
I think an -ENODEV for that purpose would make sense, and it might
be a good value to add to a new Documentation/i2c/... file. That
seems compatible with the driver model probe code, where both that
and -ENXIO are treated as "normal" errors not worthy of diagnostics.
Likewise, a standard code is needed for arbitration lost. It could
be reported any time master transmit mode is used, not just in the
send-an-address stage. Maybe -EAGAIN would suit, it already has
the right kind of message; or -EBUSY, or -EALREADY.
More information about the i2c