Subject: Re: New i2c framework
To: Jason Thorpe <firstname.lastname@example.org>
From: Eduardo Horvath <eeh@NetBSD.ORG>
Date: 07/31/2003 15:43:53
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
> * 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