At 18 Feb 2002 05:37:21 -0000, eeh@netbsd.org wrote:
> I don't know what you're talking about here.  The I2C bus specification
> defines the bus cycles and how you send out a 7-bit or 10-bit address,
> the read/write bit, and how data bytes are sent on the wire, but that's
> it.  Any protocols to communicate with the destination device are specific
> to that particular device.  Some require you send an address first then
> read or write a single data byte.  Some have an implicit data pointer which
> can be manipulated and transfer data in arbitrary sized blocks.  Some only
> transfer one byte at a time.  Some require start between each byte transferred,
> while some devices require a start only at the beginning of the operation.
> I have seen many different combinations.

SMbus standardizes that -- in approx. the same way (IIRC, one's
apprximately a subset of the other, but I forget which) -- plus a
bunch of commands to use on the bus.

There are many 'smart controllers' which know how to do the entire
bit-banging sequence for a fair number of those commands.

Individual devices can be designed to be electrically compatible with
either.


> As for interrupt driven controllers:  you load the address, load the data to
> be transferred, kick the controller to start the transfer and wait for an
> interrupt.  When the fifo underflows/overflows or the dma count reaches
> zero, you reload the device and kick it again.

It's possible to do much more than that with an interrupt driven
controller for SMbus, even with the same commands.

Your company has access to BCM1250 documentation under NDA; take a
look at the SMbus controller.


> | What about reentrancy?  i.e. command currently being processed by the
> | bus in interrupt-driven fashion, and some process sleeping for it, and
> | some other code needing to execute an op from an interrupt context?
> 
> The driver should queue commands and execute them atomically, the
> same way SCSI commands are handled.  Except I2C does not support the
> equivalent of disconnect/reselect.

OK.


> | It makes sense to have a higher level interface, in addition to this
> | 'drive these bytes' interface.  I.e., there are a bunch of standard
> | operations used by many/most devices, and it's silly to have to recode
> | them in each driver that needs them.
> 
> There are no such standards.  If there were my life would be much easier
> and I would have spent much less time debugging individual i2c device
> drivers.

There _are_ such standards: SMbus.  Go look at it.  To try to do an
i2c/smbus interface without understanding both is ... insane.  And, to
try to do an i2c interface while ignoring smbus is ... very
shortsighted.


> This particular device requires a START between each byte transfer, hence
> the I2C_REPSTART (which forces the driver for the IBM IIC controller to 
> transfer bytes one at a time because the hardware cannot be set to insert
> unecessary START phases).  If you are interested I have several other
> drivers that show completely different communications protocols.

Yup.  You may need this type of flexibility.  but there are also
common commands (in SMbus at least, but i'd be surprised if a lot of
i2c devices didn't implement them as well).


> | If the goal is to indicate read vs write parts of a single command w/
> | multiple op structures, then why do you need all of those flags for
> | each?  (the flags seem like they're 'per-command'.)
> 
> The 8-bit and 10-bit addresses overlap but are disjoint, so you need to
> be able to distinguish one from the other.  The only other flags are POLL,
> like the SCSI POLL flag, and the I2C_REPSTART flag to specify a slight
> variation in the communications protocol.  You can get the same effect as
> I2C_REPSTART by having a separate operation for each byte, but that's more
> difficult to code than just adding a flag.

oh, i think i was interpreting those as being part of the
per-structure flags field.  never mind.


> | Have you read the SMBus spec?
> 
> This is I2C bus.  What does SMBus have to do with this?

"Go look at the SMBus spec."  It's basically the same bus, just
(*cough* some would say) tweaked enough to avoid some patent issues.
8-)

To be honest, I don't know how you could properly implement an
interface for this layer without understanding both.



cgd
--
Not speaking for Broadcom Corporation, of course.