Enumerable I2C busses
M. Warner Losh
imp at bsdimp.com
Wed Jan 21 15:30:09 PST 2009
In message: <200901211542.08461.jhb at freebsd.org>
John Baldwin <jhb at FreeBSD.org> writes:
: On Wednesday 21 January 2009 3:28:05 pm M. Warner Losh wrote:
: > In message: <200901211110.33961.jhb at freebsd.org>
: > John Baldwin <jhb at FreeBSD.org> writes:
: > : On Wednesday 21 January 2009 9:47:50 am Nathan Whitehorn wrote:
: > : > John Baldwin wrote:
: > : > > On Tuesday 06 January 2009 2:24:19 pm Nathan Whitehorn wrote:
: > : > >> M. Warner Losh wrote:
: > : > >>> In message: <492AC8DE.6050902 at freebsd.org>
: > : > >>> Nathan Whitehorn <nwhitehorn at freebsd.org> writes:
: > : > >>> : M. Warner Losh wrote:
: > : > >>> : > In message: <4929C6D8.7090305 at freebsd.org>
: > : > >>> : > Nathan Whitehorn <nwhitehorn at freebsd.org> writes:
: > : > >>> : > : Rafał Jaworowski wrote:
: > : > >>> : > : >
: > : > >>> : > : > On 2008-11-23, at 19:18, Dag-Erling Smørgrav wrote:
: > : > >>> : > : >
: > : > >>> : > : >> Nathan Whitehorn <nwhitehorn at freebsd.org> 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.
: > : > >>> : >
: > : > >>> : > 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.
: > : > >>> :
: > : > >>> : Yes, this is exactly what I wanted to do, like how ofw_pci works.
: > : > >>> :
: > : > >>> : > : 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.
: > : > >>> : >
: > : > >>> : > This is the bigger problem. Today, we are stuck with a lame
: table
: > : > >>> : > that will translate the OF provided properties into FreeBSD
: driver
: > : > >>> : > names.
: > : > >>> :
: > : > >>> : At the moment, I don't believe Apple uses any of the current very
: > : small
: > : > >>> : number of I2C device drivers in tree. So I may skip the table for
: the
: > : > >>> : time being, assuming the hack below is OK. In future, this may
: change,
: > : > >>> : since G5 systems require software thermal control. But that will
: be
: > : the
: > : > >>> : subject of another mail to this list...
: > : > >>> :
: > : > >>> : > : 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.
: > : > >>> : >
: > : > >>> : > 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.
: > : > >>> : >
: > : > >>> : > 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
: > : would
: > : > >>> : > also help, but does mean changing all the i2c bus attached
: drivers
: > : in
: > : > >>> : > the tree.
: > : > >>> :
: > : > >>> : I think changing existing I2C drivers may be unavoidable. Would
: there
: > : be
: > : > >>> : any objection to changing the MI iicbus drivers to return
: > : > >>> : BUS_PROBE_NOWILDCARD in their probe routines? It seems to have
: been
: > : > >>> : introduced (by you) to solve more or less exactly this problem. By
: my
: > : > >>> : 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
: > : > >>> :
: > : > >>> : I would also like to change iicbus_probe to return -1000 like
: > : > >>> : dev/pci/pci.c to allow it to be overridden by a subclass. Please
: let
: > : me
: > : > >>> : know if this is a terrible idea or if I have forgotten any I2C
: device
: > : > >>> : 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
: > : > >>>
: > : > >> This is now in the tree. Now for part 2, which I had not considered
: > : > >> previously: connecting the I2C bus layer to the I2C host adapters.
: > : > >>
: > : > >> Right now, we have the following:
: > : > >> kiic/other i2c adapters
: > : > >> ---iicbus
: > : > >> ---ofw_iicbus
: > : > >>
: > : > >> Since kiic provides an Open Firmware node, ofw_iicbus gets priority,
: > : > >> attaches, and everything after that is wonderful. The issue is how
: best
: > : > >> to attach the iicbus modules to kiic. Current I2C controllers contain
: a
: > : > >> line like this:
: > : > >> DRIVER_MODULE(iicbus, me, iicbus_driver, iicbus_devclass, 0, 0);
: > : > >>
: > : > >> This explicitly specifies that you want the standard driver, so we
: need
: > : > >> additional glue to allow the ofw_iicbus driver to attach. One
: solution
: > : > >> is that each relevant host adapter can add an additional
: DRIVER_MODULE
: > : > >> line with the ofw_iicbus driver and class, which would have to
: exported
: > : > >> in a header somewhere. This is pretty ugly. Another solution is for
: the
: > : > >> ofw_iicbus module to grow a list of the names of interesting
: adapters.
: > : > >> This is worse.
: > : > >>
: > : > >> The third option is to do what we do for pci, where all PCI adapters
: are
: > : > >> named 'pcib'. So we could make new I2C host adapters named 'iichb' or
: > : > >> something, and then move the DRIVER_MODULE logic for new code into
: the
: > : > >> bus modules, as is done for PCI. This decreases the amount of
: > : > >> 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
: > : > > functionality) similar to the OF-aware PCI bus, then I would go the
: PCI
: > : route
: > : > > and just call it iicbus but give it a higher probe priority.
: > : > >
: > : >
: > : > Which it is. What I meant was the bridge devices to which iicbus
: > : > attaches. For pci, they all end up with the same name (pcib) so that the
: > : > pci layer knows to attach to them. For I2C, they are called
: > : > iicbb/pcf/at91_twi/etc. and each bridge device explicitly attaches the
: > : > standard iicbus to itself, instead of letting it and any firmware-aware
: > : > versions probe.
: > :
: > : I'm a bit torn on that one, especially since you have weird cases like one
: of
: > : the via parts that has both smbus and iicbus children.
: > :
: > : The other option would be to fix the attaching to subclasses thing (that
: > : should make all pci drivers attach to cardbus0 devices since cardbus
: inherits
: > : from pci, for example) and then you could have what would basically be an
: > : abstract base class "iicbridge" with no devmethods that all bridge drivers
: > : inherit from, and iicbus would attach to that.
: >
: > Right now, the only bug that I know about with the cardbus vs pci
: > thing is that kldload doesn't necessarily probe/attach pci drivers on
: > a cardbus bus. Otherwise, it works perfectly. This is the only
: > reason that we have driver lines with cardbus attachments in the pci
: > drivers at all...
:
: That is the bug though. :) I've looked at it and I think I know how to fix
: it, I just haven't gotten around to it. I think device_probe_and_attach()
: needs to actually walk up the inheritance list of the current 'bus' driver,
: but only if all of the drivers for the current 'bus' failed to probe (or
: there are no drivers).
But why then does it work with the normal probe and only fail on the
load?
Warner
More information about the freebsd-arch
mailing list