Date: Wed, 21 Jan 2009 08:43:32 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: Enumerable I2C busses Message-ID: <200901210843.33247.jhb@freebsd.org> In-Reply-To: <4963AFE3.5080607@freebsd.org> References: <4929C6D8.7090305@freebsd.org> <20081124.105800.-267230932.imp@bsdimp.com> <4963AFE3.5080607@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote: > M. Warner Losh wrote: > > In message: <492AC8DE.6050902@freebsd.org> > > Nathan Whitehorn <nwhitehorn@freebsd.org> writes: > > : M. Warner Losh wrote: > > : > In message: <4929C6D8.7090305@freebsd.org> > > : > Nathan Whitehorn <nwhitehorn@freebsd.org> writes: > > : > : Rafa=C5=82 Jaworowski wrote: > > : > : >=20 > > : > : > On 2008-11-23, at 19:18, Dag-Erling Sm=C3=B8rgrav wrote: > > : > : >=20 > > : > : >> Nathan Whitehorn <nwhitehorn@freebsd.org> writes: > > : > : >>> The current I2C bus mechanism does not support the bus adding= =20 its own > > : > : >>> children [...] > > : > : >> > > : > : >> That's because the I2C protocol does not support device=20 enumeration or > > : > : >> identification. You have to know in advance what kind of devi= ces=20 are > > : > : >> attached and at what address. Even worse, it is not uncommon = for > > : > : >> similar but not entirely compatible devices to use the same I2= C=20 address > > : > : >> (for instance, every I2C-capable RTC chip uses the same addres= s,=20 even > > : > : >> though they have different feature sets) > > : > : >=20 > > : > : > Well, hard-coded addresses and conflicting assignments between= =20 vendors=20 > > : > : > do not technically prevent from scanning the bus; actually, our= =20 current=20 > > : > : > iicbus code can do bus scaning when compiled with a diag define= =2E=20 The=20 > > : > : > problem however is some slave devices are not well-behaved, and= =20 they=20 > > : > : > don't like to be read/written to other than in very specific=20 scenario:=20 > > : > : > if polled during bus scan strange effects occur e.g. they=20 disappear from=20 > > : > : > the bus, or do not react to consecutive requests etc. > > : > :=20 > > : > : All of this is true, but perhaps my question was badly worded. Wh= at=20 I am=20 > > : > : trying to figure out is how to shove information from an out-of-b= and=20 > > : > : source (Open Firmware, in this case) into newbus without disrupti= ng=20 > > : > : existing code. In that way, my question is not I2C specific -- we= =20 run=20 > > : > : into the same issue with the Open Firmware nexus node and=20 pseudo-devices=20 > > : > : like cryptosoft that attach themselves. > > : >=20 > > : > You are looking at the problem incorrectly. In newbus, a case like > > : > this the i2c bus should be a subclass (say i2c_of) that is derived > > : > from the normal i2c bus stuff, but replaces the hints insertion of > > : > devices with OF enumeration of devices. The OF higher levels will > > : > already know to attach this kind of i2c bus to certain i2c > > : > controllers, or always on certain platforms. > > :=20 > > : Yes, this is exactly what I wanted to do, like how ofw_pci works. > > :=20 > > : > : What I want to do is to have the I2C bus add the children that th= e=20 > > : > : firmware says it has. What the firmware cannot tell in advance,=20 however,=20 > > : > : is which FreeBSD driver is responsible for those devices, and so = the=20 I2C=20 > > : > : bus driver can't know that without a translation table that I wou= ld=20 > > : > : prefer not to hack in to the bus driver. > > : >=20 > > : > This is the bigger problem. Today, we are stuck with a lame table > > : > that will translate the OF provided properties into FreeBSD driver > > : > names. > > :=20 > > : At the moment, I don't believe Apple uses any of the current very sma= ll=20 > > : number of I2C device drivers in tree. So I may skip the table for the= =20 > > : time being, assuming the hack below is OK. In future, this may change= ,=20 > > : since G5 systems require software thermal control. But that will be t= he=20 > > : subject of another mail to this list... > > :=20 > > : > : It seems reasonable to allow devices to use a real probe routine = to=20 look=20 > > : > : at the firmware's name and compatible properties, like we allow o= n=20 other=20 > > : > : Open Firmware busses. The trouble is that existing drivers don't = do=20 > > : > : this, because they expect to be attached with hints, so they will= =20 attach=20 > > : > : to all devices. I'm trying to figure out how to avoid this. > > : > :=20 > > : > : My basic question comes down to whether there is a good way in=20 newbus to=20 > > : > : handle busses that may be wholly or partially enumerated by firmw= are=20 or=20 > > : > : some other method, and may also have devices that can only attach= =20 > > : > : themselves if told to by hints. > > : >=20 > > : > Yes. This is a bit of a problem. The problem is that the existing > > : > hints mechanism combines device tree and driver tree into one, and = in > > : > such a scenario, we wind up with the problem that you have. > > : >=20 > > : > One could make the probe routines return BUS_PROBE_GENERIC, and that > > : > would help somewhat. One could also have the probe routine check to > > : > see if a specific driver is assigned to the device or not. That wo= uld > > : > also help, but does mean changing all the i2c bus attached drivers = in > > : > the tree. > > :=20 > > : I think changing existing I2C drivers may be unavoidable. Would there= be=20 > > : any objection to changing the MI iicbus drivers to return=20 > > : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have been=20 > > : introduced (by you) to solve more or less exactly this problem. By my= =20 > > : count, the relevant files are: > > : dev/iicbus/ds133x.c > > : dev/iicbus/icee.c > > : dev/iicbus/ad7418.c > > : dev/iicbus/iicsmb.c > > : dev/iicbus/ds1672.c > > : dev/iicbus/if_ic.c > > : dev/iicbus/iic.c > > :=20 > > : I would also like to change iicbus_probe to return -1000 like=20 > > : dev/pci/pci.c to allow it to be overridden by a subclass. Please let = me=20 > > : know if this is a terrible idea or if I have forgotten any I2C device= =20 > > : drivers. > > > > Short term, this is the right fix. There was an objection, I think by > > Marcel, to this approach. However, his objections were part of a > > larger set of objections and I think that we're working to solve > > those. > > > > Warner > > =20 > This is now in the tree. Now for part 2, which I had not considered=20 > previously: connecting the I2C bus layer to the I2C host adapters. >=20 > Right now, we have the following: > kiic/other i2c adapters > ---iicbus > ---ofw_iicbus >=20 > Since kiic provides an Open Firmware node, ofw_iicbus gets priority,=20 > attaches, and everything after that is wonderful. The issue is how best=20 > to attach the iicbus modules to kiic. Current I2C controllers contain a=20 > line like this: > DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0); >=20 > This explicitly specifies that you want the standard driver, so we need=20 > additional glue to allow the ofw_iicbus driver to attach. One solution=20 > is that each relevant host adapter can add an additional DRIVER_MODULE=20 > line with the ofw_iicbus driver and class, which would have to exported=20 > in a header somewhere. This is pretty ugly. Another solution is for the=20 > ofw_iicbus module to grow a list of the names of interesting adapters.=20 > This is worse. >=20 > The third option is to do what we do for pci, where all PCI adapters are= =20 > named 'pcib'. So we could make new I2C host adapters named 'iichb' or=20 > something, and then move the DRIVER_MODULE logic for new code into the=20 > bus modules, as is done for PCI. This decreases the amount of=20 > information in the device names, but seems a bit cleaner. Thoughts? > -Nathan If ofw_iicbus is simply an OF-aware version of iicbus (i.e. same=20 functionality) similar to the OF-aware PCI bus, then I would go the PCI rou= te=20 and just call it iicbus but give it a higher probe priority. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901210843.33247.jhb>