tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Fri, 7 Nov 2008 10:53:39 -0800 (PST)
Paul Goyette <> 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

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.



Home | Main Index | Thread Index | Old Index