At 18 Feb 2002 06:39:41 -0000, eeh@netbsd.org wrote:
> This is a framework for I2C, *NOT* SMbus.  SMBus may standardize
> some of these issues.  But that's immaterial for I2C devices.  The
> three I2C bus devices I've written drivers for have nothing at all
> in common in their command protocols.
> 
> It may be possible to come up with a much simpler, cleaner 
> interface for SMbus, but this is not a for SMbus.  This is for
> I2C.

So, let's step back for a moment, and think about this:

		I2C				SMBus

'random' cmd	X				X
formats

standardized	(probably some use		X
cmd fomats	the ones in SMBus, but
		they're not standardized;
		just some hw uses the same
		exact bit patterns)

bitbanged	X				X
ctlrs

char-at-a-time	X				probably
smart ctlrs

whole-cmd	probably not			X
smart ctlrs


Both also do the same types of device addressing.


What you're saying is, you're going to completely ignore the issues
around SMBus commands and smarter controllers.

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.

The bit-banging routines need to be there in both cases, and by and
large, the stupid controllers and many of the devices are the same.


Read the SMBus spec.  Look at some examples of SMBus hardware.

They're effectively the same bus with minor tweaks.

Don't make some poor sucker have to do a whole bunch of extra work
re-doing the existing drivers down the road because of
shortsightedness now.


cgd