From owner-freebsd-arch@FreeBSD.ORG Mon Nov 24 00:02:44 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B07B61065674; Mon, 24 Nov 2008 00:02:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 604168FC0A; Mon, 24 Nov 2008 00:02:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mAO025MM017664; Sun, 23 Nov 2008 17:02:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 23 Nov 2008 17:03:34 -0700 (MST) Message-Id: <20081123.170334.660270635.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <4929877B.6060307@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: nwhitehorn@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Enumerable I2C busses X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 00:02:44 -0000 In message: Marcel Moolenaar 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