Subject: Re: New i2c framework
To: Eduardo Horvath <eeh@NetBSD.ORG>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 07/30/2003 08:53:05
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.)

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

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

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

         -- Jason R. Thorpe <thorpej@wasabisystems.com>