On 19 Feb 2002 eeh@netbsd.org wrote:

> | But you also can use a smart command interface, and are remiss if you
> | don't on hardware where it's available.
> |
> | What you want from a smart controller interface is something like:
> |
> | 	if (standard command implemented in smart controller)
> | 		do it the smart way
> |
> | 	if (byte-oriented command like what your current interface handles
> | 	    && controller does that)
> | 		call a function to drive the byte-banging through the
> | 		    controller.
> |
> | 	call the function which drives the clock and data lines to
> | 		bit-bang it the slow way.
> |
> | For dumber controllers, you can just jump into one of the latter two.
> |
> | But if the interface to do the former isn't there to begin with, all
> | of the back-ends have to rototilled to handle it, when somebody does
> | the right thing.
>
> A framework for smart SMBus controllers can be easily built on a more
> general i2c framework.  But I really don't see any compelling reason
> to clutter an i2c framework with SMBus specific functionality.

I don't think the point is to clutter in SMBus-specific functionality, but
to pick an abstraction level that will smothly make use of SMBus
controllers when their support is added or present.

As I understand it, i2c and SMBus are electrically equivalent. You can
hook an i2c chip to an SMBus controller or an i2c controller. You can hook
an SMBus chip to an SMBus controller or an i2c controller. I think that's
why they should use the same interface.

That way when I write a driver for an i2c chip foo, or an SMBus chip bar,
I use an interface that does the right thing regardless of what kind of
controller the chip hangs off of. Plus, say it is an i2c chip hanging off
of an SMBus controller. Then the i2c commands issued by my driver that
overlap SMBus smart commands get automatically accelerated.

I understand that you want to add support for i2c, not SMBus. No one is
asking you to write SMBus support. What is being asked is that the i2c
design you make be done such that adding SMBus support (making it so that
the controller can recognize smart commands and act smartly with them)
later isn't a complete rototill.

You indicate that there are commands/bus sequences that are used with i2c
devices that aren't in the SMBus spec. Thus there could well be SMBus
controllers that don't support it (they don't have a bit-bang port to fall
back to). Ok. In that case, I think the i2c/SMBus code should say, "so
sorry, you loose." But I don't think that that will be a big problem.

Mainly as neither i2c nor SMBus (AFAIK) are hot-swap busses; every chip on
there the board maker put there. I think the fact that the board maker
wants all the chips to be useful (or more to the point doesn't want to
wast money on useless chips) ensures that we won't encounter a case where
functionality we want from the i2c bus can't be had since it's on an SMBus
controller w/o a bit banger.

Take care,

Bill