[i2c] [patch 2.6.24-rc1-git] i2c-algo-bit, don't yield()

[David Brownell]

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.

- Dave