Enumerable I2C busses

[M. Warner Losh]

In message: <FF5003E9-C412-47C0-A740-DAC9C9C75EAB at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> writes:
: 
: 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.

The current i2c could easily override the hints things that I added
there for platforms that didn't support a nice OF tree or the like.

: > 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.: 

I'm not saying copy it either.  I don't like it for a variety of
reasons...  I don't like the fake devtypes, for one.  It solves one
problem, but introduces an number of others that have been talked
about here.

: 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).

I think is really the right way to go.  Linux currently has a
flattened device tree that has information about what the device is,
and what it is compatible with.  The probe routines then match on the
compat field to see if they should attach or not.

This is what should be done for the Mac PPC i2c information in the OF
tree.  For the moment, we likely need a subclass of i2c to do this
properly, but in the future, I'd love to move to using something like
this to replace hints.

Warner