Re: Include spdmem(4) in GENERIC amd64 & i386 kernels?

[Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>]

On Fri, 7 Nov 2008 10:53:39 -0800 (PST)
Paul Goyette <paul%whooppee.com@localhost> wrote:

> Well, I don't think we ever tried autoconfig
I had the same problem on sparc64. On sparc64 the i2c bus is argumented
by OpenFirmWare and thus supports direct configuration through the OFW
device tree. (The same on macppc.)

I ported the device drivers from OpenBSD. OpenBSD solved the direct
configuration this way: An i2C bus driver can supply an optional scan
function to the i2c subsystem. If not NULL this function is called in
src/sys/dev/i2c/i2c.c at the end of iic_attach() after config_search_ia
(9). This scan function then traverses the OFW device tree and attaches
the devices using direct configuration. (i.e. it calls
config_found_sm_loc(9))

Disadvantage: All i2c device drivers need to support direct
configuration in there match() functions. I.e. if we want to adapt this
scheme we need to modify the match() function of all currently existing
i2c device drivers.

Advantage: If we do it we can support direct configuration with all
existing i2c devices simply by passing an extra argument to iic_attach
().

The other solution is the way macppc does it at the moment: It adds a
MD ki2c bus that direct-config attaches the devices found by OFW. It
has the advantage of not touching all existing i2c device drivers. The
disadvantage is that this needs MD ki2c bus attachments for the i2c
devices found on macppc. So the relevant i2c devices need to be split
up in several bus frontends and a chip backend.

I prefere the way OpenBSD does it. It solves the problem of dircely
configured i2c in a uniform way for all ports. With the way macppc does
it every port needs its own attachment glue through a MD i2c bus. Thus 
duplicating this attachment glue code over and over again for every port.
-- 


tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/