Enumerable I2C busses

[Marcel Moolenaar]

On Nov 23, 2008, at 8:40 AM, Nathan Whitehorn wrote:

> On Apple's PowerPC systems, the firmware device tree helpfully  
> enumerates the system's I2C busses. Marco Trillo has recently  
> written a driver for one of the system's I2C controllers in order to  
> support the attached audio codecs, and I'm trying to figure out the  
> best way to import it.
>
> The current I2C bus mechanism does not support the bus adding its  
> own children and instead relies on hints or other out-of-band  
> information for device attachment. It would be nice to do something  
> like what the firmware-assisted PCI bus drivers do (ofw_pci, for  
> instance): hijack child enumeration from the MI layer and attach  
> information from the firmware.
>
> However, since all current I2C drivers' probe() routines return 0, I  
> can't simply add the firmware devices, because as soon as the  
> probe() methods of the existing drivers are called, they will take  
> over all the devices on the bus.
>
> What is the best way to handle this?

I think the best approach is to have the probe() method
actually test for something. This is the standard thing
to do when the bus does not know a priori which driver
to instantiate. I believe that the bus should never
create a child of a specific devclass, unless instructed
by the user (read: pre-binding directives).

For ocpbus(4) (see sys/powerpc/mpc85xx/ocpbus.c and
sys/powerpc/include/ocpbus.h), we created simple defines
to identify the hardware and use that in the probe()
method to bind the driver to the right hardware, as in:

In uart(4), for example we have:

	...
         error = BUS_READ_IVAR(parent, dev, OCPBUS_IVAR_DEVTYPE,  
&devtype);
         if (error)
                 return (error);
         if (devtype != OCPBUS_DEVTYPE_UART)
                 return (ENXIO);
	...

I'm not saying to copy it, but it does demonstrate that
you can trivially implement something that eliminates
the assumption that the bus instantiates children of
a particular devclass and thus that the probe() method
can always return 0.

What we do need is a generic way (such as the OF device
tree) to describe the hardware, its resource needs and
how it's all wired together (think interrupt routing).

-- 
Marcel Moolenaar
xcllnt at mac.com