Subject: Re: New i2c framework
To: Eduardo Horvath <eeh@NetBSD.ORG>
From: Jason Thorpe <firstname.lastname@example.org>
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
* 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 <email@example.com>