From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 21:09:37 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 E2AF91065674 for ; Sun, 23 Nov 2008 21:09:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id B3A3A8FC08 for ; Sun, 23 Nov 2008 21:09:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0KAT00E001G1WB00@smtpauth1.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sun, 23 Nov 2008 15:09:37 -0600 (CST) Received: from trantor.tachypleus.net (adsl-99-154-3-101.dsl.mdsnwi.sbcglobal.net [99.154.3.101]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0KAT00DGD1FZVJ00@smtpauth1.wiscmail.wisc.edu>; Sun, 23 Nov 2008 15:09:36 -0600 (CST) Date: Sun, 23 Nov 2008 15:10:48 -0600 From: Nathan Whitehorn In-reply-to: To: =?UTF-8?B?UmFmYcWCIEphd29yb3dza2k=?= Message-id: <4929C6D8.7090305@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=99.154.3.101 X-Spam-PmxInfo: Server=avs-9, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.11.23.205819, SenderIP=99.154.3.101 References: <4929877B.6060307@freebsd.org> <86myfq9uha.fsf@ds4.des.no> User-Agent: Thunderbird 2.0.0.17 (X11/20080928) Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , 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 21:09:38 -0000 Rafał Jaworowski wrote: > > On 2008-11-23, at 19:18, Dag-Erling Smørgrav wrote: > >> Nathan Whitehorn writes: >>> The current I2C bus mechanism does not support the bus adding its own >>> children [...] >> >> That's because the I2C protocol does not support device enumeration or >> identification. You have to know in advance what kind of devices are >> attached and at what address. Even worse, it is not uncommon for >> similar but not entirely compatible devices to use the same I2C address >> (for instance, every I2C-capable RTC chip uses the same address, even >> though they have different feature sets) > > Well, hard-coded addresses and conflicting assignments between vendors > do not technically prevent from scanning the bus; actually, our current > iicbus code can do bus scaning when compiled with a diag define. The > problem however is some slave devices are not well-behaved, and they > don't like to be read/written to other than in very specific scenario: > if polled during bus scan strange effects occur e.g. they disappear from > the bus, or do not react to consecutive requests etc. All of this is true, but perhaps my question was badly worded. What I am trying to figure out is how to shove information from an out-of-band source (Open Firmware, in this case) into newbus without disrupting existing code. In that way, my question is not I2C specific -- we run into the same issue with the Open Firmware nexus node and pseudo-devices like cryptosoft that attach themselves. What I want to do is to have the I2C bus add the children that the firmware says it has. What the firmware cannot tell in advance, however, is which FreeBSD driver is responsible for those devices, and so the I2C bus driver can't know that without a translation table that I would prefer not to hack in to the bus driver. It seems reasonable to allow devices to use a real probe routine to look at the firmware's name and compatible properties, like we allow on other Open Firmware busses. The trouble is that existing drivers don't do this, because they expect to be attached with hints, so they will attach to all devices. I'm trying to figure out how to avoid this. My basic question comes down to whether there is a good way in newbus to handle busses that may be wholly or partially enumerated by firmware or some other method, and may also have devices that can only attach themselves if told to by hints. > Nathan, not sure if this helps you, but I have a nice i2c diagnostic > tool, which among other features lets the user scan the I2C bus for > present slave devices. This is done from userland, so doing similar > thing in-kernel wouldn't be a problem. I was planning to post this for > review this coming week, so you can have a look. It's not directly useful, no, but that's a very useful tool that will be handy to have. -Nathan