On Wed, Jul 30, 2003 at 08:53:05AM -0700, Jason Thorpe wrote:
> Reply CC'd to tech-kern .. Eduardo, in the future, please ensure that 
> your replies are CC'd to tech-kern for threads on tech-kern.
> 
> On Wednesday, July 30, 2003, at 08:45  AM, Eduardo Horvath wrote:
> 
> >1) How do you handle 7-bit and 10-bit addresses?
> 
> The mid-layer doesn't have to care about them.  They are handled (or 
> not) by the back-end.  (Some controllers can do 10-bit, some cannot.)

But they are separate address spaces, so don't you need some way to
differentiate between communications to a 7-bit device or a 10-bit
device at the same address?

> >2) How is the I2C bus probed?
> 
> Indirect configuration.  It is not possible to do direct configuration 
> of an I2C bus.  While the I2C address does, to a certain extent, define 
> the "device type", not all devices that have a common I2C address are 
> software compatible.  Some examples:
> 
> 	* There are a few RTCs out there that are not
> 	  software compatible but which use the address
> 	  0x68.
> 
> 	* There are a few RTCs out there that have the
> 	  address 0x50, which happens to also be a standard
> 	  address for I2C EEPROMs.

Huh?  How does that prevent you from doing direct configuration?

> >3) How do you specify the requirement for repeated
> >starts on multi-byte reads and writes?
> 
> If a device requires REPEATED START between each byte of a multi-byte 
> read, then the device driver simply calls iic_exec() multiple times.

Ick.  So instead of issuing one command to an intelligent I2C controller
you need to issue a dozen commands.  Doesn't that sort of defeat the
purpose of having an intelligent I2C controller?

> >4) What happens if something starts a series of operations
> >on the bus but does not send a stop at the end?
> 
> That is a programming error; I suppose one thing to possibly prevent 
> this is to check if a STOP has been sent in iic_release_bus(), and send 
> one if not.
> 
> >5) What happens if a userland program which does a series of
> >operations through the ioctl interface and is rescheduled
> >between two of them and something else attempts to use the
> >bus (as in 4 above)?
> 
> The userland interface is not allowed to hold the bus lock between 
> ioctl calls precisely for this reason.

So...  How does a userland program issue commands that require
repeated starts?

Eduardo