MI I^2C drivers
Ben Harris
systems use attaches to an I^2C bus, so I want an MI I^2C infrastructure
for it. ]
Currently, there seem to be at least three sets of infrastructure in the
kernel for handling Philips' I^2C bus. There's the MI stuff in
sys/dev/i2c, and MD stuff in sys/arch/arm26/ioc/{iic,rtc}.c and
sys/arch/arm32/dev/{iic,rtc}.c. This is clearly silly.
The reason I didn't use the MI stuff for arm26 is that it doesn't present
a real bus -- instead, it provides an attribute to attach to a
device. This seems fine if it's being used within one device, but it's
less than optimal if we want to have devices (from the NetBSD point of
view) attached to an I^2C bus, which I would.
On the other hand, a real bus is likely to be awkward if you _do_ want to
treat it as part of a device, since you don't want your I^2C EEPROM being
a device in its own right (do you?).
Any thoughts from the rest of the world on this kind of thing? If not,
I'll start hacking and see what I come up with.
--
Ben Harris <bj...@netbsd.org>
Portmaster, NetBSD/arm26 <URL:http://www.netbsd.org/Ports/arm26/>
Castor Fu
. . .
> [ Prompted by pk's TOD clock interface, and the fact the clock Acorn
> systems use attaches to an I^2C bus, so I want an MI I^2C infrastructure
> for it. ]
>
> Currently, there seem to be at least three sets of infrastructure in the
> kernel for handling Philips' I^2C bus. There's the MI stuff in
> sys/dev/i2c, and MD stuff in sys/arch/arm26/ioc/{iic,rtc}.c and
> sys/arch/arm32/dev/{iic,rtc}.c. This is clearly silly.
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.
Things get even more complicated if you want to support multiple
masters, but I don't know of any systems which take advantage of
that part of I2C.
I've heard rumors that cgd has similar requirements to ours. . .
If people think this is of general interest we can start iterating on
a common framework.
-castor
Ben Harris
> 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?
Ken Hornstein
>treat it as part of a device, since you don't want your I^2C EEPROM being
>a device in its own right (do you?).
I'm sure someone will correct me if I'm wrong, but I am under the impression
that a "real" bus is used for the MII/PHY interface found on most newer
Ethernet cards. You could look at that code for an idea of how it works.
--Ken
Jason R Thorpe
> 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.
>
> Things get even more complicated if you want to support multiple
> masters, but I don't know of any systems which take advantage of
> that part of I2C.
>
> I've heard rumors that cgd has similar requirements to ours. . .
>
> If people think this is of general interest we can start iterating on
> a common framework.
Also take into consideration SMBus, please, and the fact that not all
host controllers are bit-bangers.
--
-- Jason R. Thorpe <tho...@zembu.com>
Manuel Bouyer
> 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.
Yes, I wrote this for the eeprom attached to the ThunderLAN-based ethernets
I have. I though it would be eventually be used for similar requirements
of other ethernet or scsi adapters, but not much more.
I'm not sure this can be handled by a real bus at all, as there doesn't seem
to be any device adress here (it was a long time ago ... I don't remember :)
>
> 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
As does i2c on the ThunderLAN.
--
Manuel Bouyer <bou...@antioche.eu.org>
--
Matthew Jacob
Whatever you doe for i2c in an MI way, can you think about how it might fit
with the Alpha 4100 embedded i2c stuff (embedded on the motherboard)?
Chris G. Demetriou
I've been looking at doing something Real w.r.t. this, in the last few
days. (I'm familiar with what's been done by the Geocast folks,
thanks to jeffs, as well as the code in our source tree.)
(BTW, there's actually at least one smbus-ish implementation missed in
the list of implementations Ben posted: the pmax dtop bits, which are
access.bus.)
In a nutshell, you need both real bus and "usable from devices without
a bus abstraction" for the code to be sane.
How about I poke at it for a bit, and post stuff here before too long.
If anybody has any input besides the stuff already mentioned, i'd be
glad to hear about it. (The facilities that the Geocast folks need
are much more interesting than i'd thought.)
chris
Jason R Thorpe
> Whatever you doe for i2c in an MI way, can you think about how it might fit
> with the Alpha 4100 embedded i2c stuff (embedded on the motherboard)?
...and the AlphaServer 1000, which has a PCD8584 at ISA 0x530.
I haven't investigated with 1200/4100 I2C controller too much yet, tho,
but considering how warm it gets in my attic sometimes, I think I might
have to soon :-)
Matthew Jacob
Heh. Not in San Francisco, really, no...
(oh, okay, there *are* some hot days- but those are the days you shut it down
and wander out to Baker Beach...)