From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 19:28:01 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 3118E1065670 for ; Sun, 23 Nov 2008 19:28:01 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1DCE78FC14 for ; Sun, 23 Nov 2008 19:28:01 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.95] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KAS00424TYN2I00@asmtp021.mac.com>; Sun, 23 Nov 2008 10:28:01 -0800 (PST) Message-id: From: Marcel Moolenaar To: Nathan Whitehorn In-reply-to: <4929877B.6060307@freebsd.org> Date: Sun, 23 Nov 2008 10:27:59 -0800 References: <4929877B.6060307@freebsd.org> X-Mailer: Apple Mail (2.929.2) Cc: 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: Sun, 23 Nov 2008 19:28:01 -0000 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