| At 18 Feb 2002 07:29:02 -0000, eeh@netbsd.org wrote:
|
| > | What that means is that when somebody comes along and does the single
| > | interface for both smbus and i2c _right_, they'll probably have to
| > | completely redo the interface between command issuers and command
| > | processors, specifically to accomodate representation of
| > | 'standardized' commands so that the front-end doesn't have to
| > | transform them into byte-ops, and the back-end doesn't have to
| > | recognize patterns of byte-ops and optimize them.
| > 
| > While an SMBbus framework can be built upon an I2C framework, just 
| > as a generic I2C framework can be built on the existing i2c_bus bitbang
| > operations, the opposite is not true.  SMBus controllers that handle
| > complete command sequences are incompatible with I2C.
|
| You should really follow my suggestion, and, for instance, look at the
| BCM1250 user manual (which you have under NDA, as I mentioned before).
| And also the SMBus spec.
|
| Or, just look at the table I mentioned in the previous:
|
| While there are standardized SMBus commands, devices also implement
| operations which are not standardized, and controllers implement
| bitbang interfaces to accomodate them.
|
| (Like I believe I said) you still need the bitbang-handling code for
| smbus.

I don't see that anywhere in the SMBus specification.

A strictly conforming SMBus controller does not need to provide a
bitbang interface.  In order to communicate to i2c devices, such
an interface or its equivalent is required.  Are you advocating
a SMBus framework that cannot be made to work on SMBus controllers
that do not provide a bitbang interface?

| 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.

Eduardo