Subject: Re: New i2c framework
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/17/2002 23:07:49
At 18 Feb 2002 06:39:41 -0000, email@example.com 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
So, let's step back for a moment, and think about this:
'random' cmd X X
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
char-at-a-time X probably
whole-cmd probably not X
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