From owner-freebsd-arch@FreeBSD.ORG Sun Nov 23 20:30:06 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 821181065673 for ; Sun, 23 Nov 2008 20:30:06 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 571F78FC0C for ; Sun, 23 Nov 2008 20:30:06 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mANKJ8W6014478; Sun, 23 Nov 2008 13:19:09 -0700 Received: from apn-77-112-41-180.gprs.plus.pl (apn-77-112-41-180.gprs.plus.pl [77.112.41.180]) by mail.semihalf.com (Postfix) with ESMTP id C4F9514C66; Sun, 23 Nov 2008 21:34:49 +0100 (CET) Message-Id: From: =?ISO-8859-2?Q?Rafa=B3_Jaworowski?= To: =?UTF-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86myfq9uha.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 23 Nov 2008 21:18:54 +0100 References: <4929877B.6060307@freebsd.org> <86myfq9uha.fsf@ds4.des.no> X-Mailer: Apple Mail (2.929.2) Cc: Nathan Whitehorn , 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 20:30:06 -0000 On 2008-11-23, at 19:18, Dag-Erling Sm=C3=B8rgrav 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 =20 > 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 =20= do not technically prevent from scanning the bus; actually, our =20 current iicbus code can do bus scaning when compiled with a diag =20 define. The problem however is some slave devices are not well-=20 behaved, and they don't like to be read/written to other than in very =20= specific scenario: if polled during bus scan strange effects occur =20 e.g. they disappear from the bus, or do not react to consecutive =20 requests etc. Nathan, not sure if this helps you, but I have a nice i2c diagnostic =20 tool, which among other features lets the user scan the I2C bus for =20 present slave devices. This is done from userland, so doing similar =20 thing in-kernel wouldn't be a problem. I was planning to post this for =20= review this coming week, so you can have a look. Rafal=