Re: question about enumeration of buses on arm systems with dtb files

[mlelstv%serpens.de@localhost (Michael van Elst)]

campbell+netbsd-tech-kern%mumble.net@localhost (Taylor R Campbell) writes:

>I think usually it's first-come-first-serve according to the ordering
>in the device tree (that is, in a pre-order traversal, which is the
>same as the sequential order in the .dts file) -- not necessarily the
>numbers in the device tree node names.  So if there device tree lists
>nodes i2c2, i2c0, i2c1, in that order, then it'll be

>/dev/iic0 -> i2c2
>/dev/iic1 -> i2c0
>/dev/iic2 -> i2c1


If you enable all interfaces (status = 'okay' in DTS) you get:

% ofctl -p | grep /i2c@
00002474:     /i2c@7e205000
00002fa4:     /i2c@7e804000
000030a0:     /i2c@7e805000

This is also the order in the DTB:

                i2c@7e205000 {
                        phandle = <0x46>;
...
                i2c@7e804000 {
                        phandle = <0x4d>;
...
                i2c@7e805000 {
                        phandle = <0x15>;
...


In dmesg you will just see:

bsciic0 at simplebus1: Broadcom Serial Controller
iic0 at bsciic0: I2C bus
bsciic1 at simplebus1: Broadcom Serial Controller
iic1 at bsciic1: I2C bus
bsciic2 at simplebus1: Broadcom Serial Controller
iic2 at bsciic2: I2C bus

But with drvctl you can see that the order is different.

% drvctl -p bsciic0 fdt-path
/soc/i2c@7e805000
% drvctl -p bsciic1 fdt-path
/soc/i2c@7e205000
% drvctl -p bsciic2 fdt-path
/soc/i2c@7e804000

The FDT code sorts nodes by an 'order' value, which currently
is the phandle number, see the fdt_get_order() function.


Another issue is that depending on the RPI model, different
I2C interfaces are used by the VideoCore and attaching the
driver may break functionality, so you normally do not
attach all 3 interfaces but just the one that is routed to
the GPIO pins.