RFC: extension of libi2c to support SPI aswell

Aaron J. Grier aaron at frye.com
Wed Sep 5 18:40:21 UTC 2007


On Wed, Sep 05, 2007 at 09:39:37AM -0400, Robert S. Grimes wrote:
> On another project, I did some investigation into how Linux does this,
> and the newer model seems to address these issues, at least in theory.
> I don't know if their approach is overkill or not; perhaps someone who
> has used it can comment?

NetBSD has kernel APIs for i2c, SPI, and dallas/maxim 1wire.  the SPI
driver doesn't appear to address the odd chip select issues.  the i2c
driver is in a little better shape, and has been employed to read the
serial presence detect (SPD) data from RAM modules in NetBSD-current.
I've thrown in 1wire since it seems related...

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/i2c/
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/spi/
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/onewire/

to deal with SPI, device-specific callbacks for setup and teardown might
be a generic way to handle the odd cases and set up necessary chip
selects.

1wire most closely matches to i2c, in that it's a multi-drop bus with an
enumeration process.  the i2c driver could probably be extended to use
it if desired.

I have all three serial interfaces in my shipping product (plus RS232),
and wrote my own drivers for them back in 2001...  hopefully I'll be
allocated some time here early next year to pull-up all our in-house
drivers.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com



More information about the users mailing list