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?

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.

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

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



anyway, i'm in a rush, and my time for this discussion has expired...


cgd