Subject: Re: MI I^2C drivers
To: Castor Fu <>
From: Ben Harris <>
List: tech-kern
Date: 07/26/2000 18:48:58
On Wed, 26 Jul 2000, Castor Fu wrote:

> But the stuff in sys/dev/i2c is just not that useful.  We wanted a more
> general framework.  On our system we have something like the following:
> 	cai2c0  at chipa?
> 	iicbus* at cai2c?
> 	zot0 at iicbus? slaveaddr 0x34          # normalized slave address 
> 	bar0 at iicbus? slaveaddr 0x46          # normalized slave address
> The iicbus device has an ioctl for servicing raw io requests through
> the interface which is also used by child devices.  
> The io requests at the read/write multiple bytes to support devices
> like ours where the I2C interface can spit out multiple bytes at a time. 

That's roughly how the arm{26,32} iic device works, except there's no
user-visible "iicbus" device to allow generic access.  I suspect that
would be better done using an "iicgen" device or similar to provide
user access to a particular slave.

> If people think this is of general interest we can start iterating on
> a common framework.

How would you propose handling the case where (say) a SCSI card has an
I^2C bus that it uses privately to connect an EEPROM containing its
configuration?  That seems to be the current target of sys/dev/i2c.

We also need some idea of the interface to the low-level driver.  The
Acorn interfaces are bit-banged by the CPU.  How do more sophisticated
interfaces work?

Ben Harris                                                   <>
Portmaster, NetBSD/arm26               <URL:>