Subject: Re: New i2c framework
To: NetBSD Kernel Technical Discussion List <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 02/20/2002 13:48:42
In message <20020220084714.5B89FB5@proven.weird.com>Greg A. Woods writes
>In other words a plain simple straight i2c interface is always going to
>be useful for instances where all you have is an i2c bus.
Nobody ever said it isn't useful. It's not *always* best, though.
Suppose someone takes a native I2c controller (like some of the via
apollo?), and wires a native SMBus device behind it (say, an lm78).
Then a better design than othe one on the table is an SMBus-style
(QUICK/BYTE[rw]/BLOCK[rw] &c) API, in software, as part of the
interface of all i2c-like devices.
OTOH, if the i2c[sic] device you want to talk to is behind a PIIX4, (or
Serverworks clone), or an ALI 1535 or AMD 756 or Intel 801 or viapro
(or an Apple Keywest?), then the only option you have is SMBus ops.
>However when you have an SMBus you probably only want to talk to SMBus
>devices, not any i2c devices that may be front-ended by them [...]
Maybe, maybe not. Thats where the commments on the proposed
Havard, how about this:
1. Extend the proposed i2c(9), to include SMBus primitives.
2. Note that NetBSD may support ``i2c busses'' attached via SMBus
controllers, where only the SMBus primitives are supported;
3. provide an i2c bitbang statemachine to do SMBus-style transactions
(to lm78s, &c), for attachments where the "i2c" controller doesn't
do SMBus in hardware?
This may still not be OK (IPMI? ICMB?), but it seems a closer match
to hardware "out there" today than just raw bitbanging.