Date: Sun, 23 Nov 2008 10:27:59 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses Message-ID: <FF5003E9-C412-47C0-A740-DAC9C9C75EAB@mac.com> In-Reply-To: <4929877B.6060307@freebsd.org> References: <4929877B.6060307@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FF5003E9-C412-47C0-A740-DAC9C9C75EAB>