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                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>