Subject: Re: New i2c framework
To: None <firstname.lastname@example.org, email@example.com>
From: None <firstname.lastname@example.org>
Date: 02/19/2002 20:13:55
| At 19 Feb 2002 19:48:19 -0000, wrote:
| > | > A framework for smart SMBus controllers can be easily built on a more
| > | > general i2c framework.
| > |
| > | How do you figure? you need to expose the well-defined smbus commands
| > | all the way through the interface, or every back-end driver has to
| > | look at the commands that it sees, and try to recognize them as
| > | specific smbus commands.
| > I'd have thought that was obvious. You create a SMBus interface which
| > SMBus devices call to generate a series i2c operations, then call
| > i2c_cmd() as often as required to process the i2c commands. SMOP.
| And how do smart controllers use that?
| they get called separately by that smbus interface? or they grok the
| results of 'i2c_cmd' and turn them back into smart commands?
They get called by the smbus interface.
| The point is, how do you do this without inventing a new set of
| interfaces and add a whole new set of code, for smbus controllers,
| when really it _is_ the same code that needs to be written.
It *IS NOT* the same code.
| the only difference is that on 'real i2c' there's a higher likelyhood
| of needing commands with a non-standard format, which _need_ to be
There is *_NO_ _STANDARD_ _I2C_ _FORMAT_*!!!!!
Pretending that there is a standard i2c format is merely going to
cause headaches for people who discover that the SMBus commands they
used to communicate to a i2c device, because they thought they were
shorthand i2c commands, simply don't work.
| in i2c devices (which may appear on smbus) which _can_ use the
| higher-level command formats, you _should_ use higher-level command
| formats, to make the drivers clearer and to make the code more easily
| shared between the busses (and higher-performance, when there's a
| smart controller).
This idea is soooo broken in soooo many ways I really don't want to go