For a few months now, I've been working on improving the auto configuration of
I2C and SPI devices. These busses, of course, are not self-enumerating, and
besides indirect configuration of devices listed in a kernel config file,
enumerating based on information in platform config data (e.g. Devicetree,
OpenFirmware, ACPI) was supported by having controller drivers explicitly call
OpenFirmrware, FDT, or ACPI-specific code to populate a dictionary. Yuck.
My new mechanism instead uses the platform config data to enumerate the devices
directly, without having to get a dictionary involved at all. It also provides
a tidier mechanism to pass device handles to each driver via the normal
mechanism, rather than using the i2c_attch_args::ia_cookie /
i2c_attch_args::ia_cookietype hack.
The basic idea involves the device call mechanism I introduced a while ago.
The various back-ends (OpenFirmware, ACPI, etc.) that have I2C and SPI bus
bindings define "i2c-enumerate-devices" and "spi-enumerate-devices" device
calls. Those calls in turn invoke a callback to the I2C or SPI code to
actually attach the device specified in the platform config data. There is no
duplication of information in a dictionary, and the device handles for the
child devices naturally flow from the enumeration.
Systems that lack a platform device tree (e.g. sandpoint) or that have missing
device tree nodes on some models (e.g. sparc64, macppc) have the option of
using static tables, and there are helper functions in the core I2C code to
facilitate this. Such platforms merely need to subclass the controller's
devhandle and override that handle's "i2c-enumerate-devices" call. This also
covers the case where a platform that uses OpenFirmware has a controller whose
child nodes, for whatever weird reasons, don't conform to the standard bindings
(such is the case with the "ki2c" controller on macppc).
While the changes are very straightforward, the diffs are large, so I've broken
them up into chunks that are easier to digest and describe. Sometimes the
diffs might not make a lot of sense because of a larger restructuring, so in
those cases, I encourage you to check out the thorpej-i2c-spi-conf2 branch and
simply read the file directly.
I'll start with the core I2C changes:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-core-diffs.txt
The main changes here iic_attach(). The loop enumerating a prop_array_t of
child device descriptions is gone, and has been replaced by the following small
code block:
struct i2c_enumerate_devices_args enumargs = {
.ia = &ia,
.callback = iic_enumerate_devices_callback,
};
rv = device_call(self, "i2c-enumerate-devices", &enumargs);
The iic_enumerate_devices_callback() is quite small -- it essentially just
calls config_found() and performs some housekeeping.
You'll also see some other helpers there, like i2c_enumerate_deventries(),
which helps to support the "static tables of devices" scenario I mentioned
above.
In addition to the enumeration change, I've changed the code to not use a flat
array of device_t pointers indexed by i2c address. That array was consuming 4K
or 8K of memory (depending on pointer size) for what is typically very sparsely
populated -- what a waste! It now uses a linked list of device entries, sorted
by i2c address, and the manipulation of that list is MP-safe.
Also included in these diffs is a helper function in kern/subr_device.c that
does the work of subclassing a device handle in the common case (used by macppc
and sparc64; there is one additional case in macppc that's more complicated, so
that location is open-coded -- more on that later).
Next, let's take a look at the changes to the platform config data back-ends:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-acpi-diffs.txt
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-ofw-diffs.txt
Now, rather than allocating a populating a dictionary with platform config
data, that data is used to directly enumerate and attach child devices.
In the OpenFirmware case, the old code that did this has been tossed
completely, and the differences between OpenFirmware variants (including the
standard Devicetree bindings) is handled in a much tidier way. Also, because
there is no more of_enter_i2c_devs() function, there is no more need for a
fdtbus_attach_i2cbus() (FDT-based attachments just attach the "iicbus" instance
like any other attachment would); note there is still a need for
fdtbus_register_i2c_controller(), but that is not anything that's I2C or SPI
specific in the FDT universe, and I'm not intending to address that issue now.
All of these changes made it necessary to adjust some (but certainly not all)
I2C device drivers, mainly things that needed to make use of
i2c_attch_args::ia_cookie / i2c_attch_args::ia_cookietype. Those diffs are
here:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-mux-diffs.txt
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-device-diffs.txt
The MUX changes are a little larger, and spread across multiple files, so I
carved them out separately.
Now let's take a look at the simple controller diffs:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-controller-diffs.txt
As you can see, the main changes here are to eliminate FDT- and ACPI-specific
code, making the two cases identical. I did not do the more invasive
re-factoring of these to fully de-duplicate the code that's now the same, but
that is a fairly straight-forward exercise. Additionally, a bunch of code that
existed to populate the child device dictionary has been garbage-collected from
a couple of machine-dependent I2C controller drivers (those instances can use
the standard OpenFirmware bindings).
Controllers that have built-in MUXes (the kind that the Devicetree I2C bindings
call an "i2c-mux-reg"), including "ki2c" and "smu" on macppc and "pfciic" on
sparc64, now independently attach the two channels. I may at some point in the
future revisit how these controllers work. Unfortunately, for the uses in
NetBSD, the device trees on these platforms fall squarely into the "legacy"
category and they don't really represent the topology in standardized ways
(sparc64, for example, encodes the MUX bus number in the upper 32-bits of a
64-bit address cell, even on i2c controllers that don't have a MUX, and the
macppc case is of course weirder than that). In any case, general support for
"i2c-mux-reg" MUXes is not included here, but the core I2C code can now at
least express the MUX bus number in these cases along with the more
standardized I2C MUX cases.
Another change I made was to remove the needless indirection of "smuiic" on
macppc; the "iicbus" instances now attach directly to "smu".
And now for the more complicated cases ... the ones that need to override the
standard "i2c-enumerate-devices" call.
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/i2c-override-diffs.txt
There are 4 instances of this: 2 controllers on macppc ("cuda" and "ki2c"), the
sandpoint platform, and sparc64 (specific machine models, not specific to any
specific controller type).
First, "cuda". This one is pretty basic. There are no child nodes in the
device tree. We populate a table and call i2c_enumerate_deventries() from the
"i2c-enumerate-devices" call.
Second, "ki2c". This one is a bit wackier. In this case, all of the child
nodes are there, but the device tree doesn't match the OpenFirmware bindings
like *at all*. Complicating this one is the fact that there are two schemes
found on "ki2c", depending on the OpenFirmware version. The comment I added
explains it best:
+ /*
+ * Different systems have different I2C device tree topologies.
+ *
+ * Some systems use a scheme like this:
+ *
+ * /u3@0,f8000000/i2c@f8001000/temp-monitor@98
+ * /u3@0,f8000000/i2c@f8001000/fan@15e
+ *
+ * Here, we see the channel encoded in bit #8 of the address.
+ *
+ * Other systems use a scheme like this:
+ *
+ * /ht@0,f2000000/pci@4000,0,0/mac-io@7/i2c@18000/i2c-bus@0
+ * /ht@0,f2000000/pci@4000,0,0/mac-io@7/i2c@18000/i2c-bus@0/codec@8c
+ *
+ * /u4@0,f8000000/i2c@f8001000/i2c-bus@1
+ * /u4@0,f8000000/i2c@f8001000/i2c-bus@1/temp-monitor@94
+ *
+ * Here, a separate device tree node represents the channel.
+ * Note that in BOTH cases, the I2C address of the devices are
+ * shifted left by 1 (as it would be on the wire to leave room
+ * for the read/write bit).
+ *
+ * So, what we're going to do here is look for i2c-bus nodes. If
+ * we find them, we remember those phandles, and will use them for
+ * device enumeration. If we don't, then we will use the controller
+ * phandle for device enumeration and filter based on the channel
+ * bit in the "reg" property.
+ */
Note the diff for "ki2c" is misleadingly large, because I cleaned up the code a
little while I was there, plus there's the MUX changes I mentioned earlier.
Third is the sandpoint platform. We need to select the right static list of
devices depending on the specific NAS model we're running on. This is an
example use of the DEVHANDLE_TYPE_PRIVATE devhandles; the sandpoint platform
does not use FDT or any other type of platform config data scheme, and so we're
not subclassing here, but rather creating it from whole cloth. Anyway, once
the table is selected, i2c_enumerate_deventries() actually performs the
enumeration.
The final case is sparc64. This is a case where the OpenFirmware device tree
is simply missing a bunch of child nodes. This is also tangled up with some
other "add properties for GPIO pins" stuff that jdc@ added to the port a while
ago. I kept his GPIO property fixup stuff, but completely replaced the
previous I2C fixup code he had with the new scheme. And rather than being
handled inline in device_register(), we call out to a table-driven mechanism
for matching the platforms and the specific OpenFirmware device tree nodes that
need to be fixed up. We don't rely on fixing up any specific controller driver
the way we do on macppc. Also note that not ALL of the device tree nodes are
missing! For example, on the V210, the I2C child nodes for the GPIO
controllers are present, but the nodes for the environmental sensors are not.
So, the in this case the subclass's "i2c-enumerate-devices" call first calls
the superclass's "i2c-enumerate-devices" (to enumerate the nodes present in
OpenFirmware) and then calls i2c_enumerate_deventries() to enumerate the
model-specific table of additions.
OK! That's I2C! Now onto SPI.
The general gist of the SPI changes is basically the same, and it suffered from
the same basic ugly bits as the I2C code did. Here are the core SPI changes:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/spi-core-diffs.txt
Because we don't support wildcarding of the chip select locator on SPI, direct
and indirect config using this scheme are nearly identical... in the direct
config case, we're enumerating the platform config data (only Devicetree
bindings for now) using the "spi-enumerate-devices" device call or enumerating
kernel configuration directives using config_search(). In any case, I took the
opportunity to tidy up some of the bookkeeping on how child devices are tracked.
I only provided an OpenFirmware / Devicetree "spi-enumerate-devices"
implementation. As with I2C, there is no longer a need for
fdtbus_attach_spibus(). I also tweaked fdtbus_register_spi_controller() to
remove a pointless layer of indirection, as was done for I2C a while ago.
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/spi-ofw-diffs.txt
The controller diffs are pretty straightforward. I standardized the style of
the config_found() call sites and made sure to get the controller's devhandle
passed down to the "spi" bus instance.
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/spi-controller-diffs.txt
Now, the device diffs:
https://www.netbsd.org/~thorpej/thorpej-i2c-spi-conf2/spi-device-diffs.txt
There's kind of a lot going on here, but before I dive into each one, there are
a couple of changes I made to basically all of these drivers:
- Standardize the form of the "match" function.
- Ensure "match" does not have side-effects (e.g. setting the mode/speed of the
that "slot").
- Fleshed out the compat_data[], and ensured that all of them support direct
configuration using compat data.
And now some specific additional items:
mcp23s17.c -- Added direct configuration support, which required adding
additional code to parse the device tree properties so as to be able to de-mux
the chip select (TL;DR - go read the chip's data sheet and the Devicetree
bindings for this device).
mcp3k.c -- Added direct configuration support, including selection of
parameters based on the "compatible" property from the device tree.
mcp48x1.c -- Same.
ssdfb_spi.c -- Tidied up the FDT integration a bit.
tmp121.c -- Added place-holders for other versions of the chip that we should
support eventually.
Anyway, if you've read this far, congratulations! Now, I need your help. I
don't have all of these machines. I've done a fair bit of testing on evbarm
(FDT) and macppc, but not every model. I need help specifically with:
-- evbarm (ACPI), specifically a system with an I2C MUX (I think jmcneill@ has
such a beast).
-- macppc (variety of models) -- macallan@?
-- sandpoint (any will do; I bought a Synology, but the Ethernet interface
failed after a couple of days, even PPCBOOT complains, boo). rin@?
-- sparc64 -- I don't think Qemu can emulate any of the I2C controllers that
system has. jdc@?
-- SPI devices -- tnn@?
I have some additional changes teed up for "ihidev", but I first need to finish
writing some Arduino code to simulate a I2C HID mouse so I can test it, so I'm
not including any of that bigger change here.
Anyway, comments please!
-- thorpej
