Another problem with I2C multiplexer bus naming

I am working on a BeagleBone Black (BBB) Cape that contains a PCA9548 multiplexer (mux). The BBB uses two I2C buses, i2c-0 for power management and i2c-2 for Cape discovery and other general use. I have created a dtsi file to describe the mux on my Cape per the Linux Documentation instructions.

...

&i2c2 {
    i2cmux@77 {
         compatible = "nxp,pca9548";
         #address-cells = <1>;
         #size-cells = <0>;
         reg = <0x77>;
};

...

When I boot Linux (3.14 kernel) without the cape attached I see i2c-0 and i2c-2...

ubuntu@arm:~$ ls /dev/i2* 
/dev/i2c-0  /dev/i2c-2
ubuntu@arm:~$ i2cdetect -l
i2c-0    i2c           OMAP I2C adapter                    I2C adapter
i2c-2    i2c           OMAP I2C adapter                    I2C adapter

But, I can also see in dmesg that i2c-0 probing is deferred until after i2c-2.

[    2.186756] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe
[    2.186803] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    2.193949] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
...snipped...
[    2.965899] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    2.967376] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.967500] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

This causes a problem when I boot with the Cape attached.
1) Probing is deferred on i2c-0.
2) i2c-2 is probed, the mux is discovered, and the child buses are

    assigned i2c-0, i2c-1, and i2c-3 through i2c-8.

3) The original i2c-0 bus is then probed, but since it requires the name i2c-0 and that name is already used, adapter addition fails.

ubuntu@arm:~$ ls /dev/i2* 
/dev/i2c-0  /dev/i2c-2  /dev/i2c-4  /dev/i2c-6  /dev/i2c-8
/dev/i2c-1  /dev/i2c-3  /dev/i2c-5  /dev/i2c-7
ubuntu@arm:~$ i2cdetect -l
i2c-0    i2c           i2c-2-mux (chan_id 0)               I2C adapter
i2c-1    i2c           i2c-2-mux (chan_id 1)               I2C adapter
i2c-2    i2c           OMAP I2C adapter                    I2C adapter
i2c-3    i2c           i2c-2-mux (chan_id 2)               I2C adapter
i2c-4    i2c           i2c-2-mux (chan_id 3)               I2C adapter
i2c-5    i2c           i2c-2-mux (chan_id 4)               I2C adapter
i2c-6    i2c           i2c-2-mux (chan_id 5)               I2C adapter
i2c-7    i2c           i2c-2-mux (chan_id 6)               I2C adapter
i2c-8    i2c           i2c-2-mux (chan_id 7)               I2C adapter

[    2.186754] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe
[    2.186802] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    2.193953] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
...snipped...
[    2.753254] i2c /dev entries driver
[    2.756232] i2c i2c-2: Added multiplexed i2c bus 0
[    2.756992] i2c i2c-2: Added multiplexed i2c bus 1
[    2.757690] i2c i2c-2: Added multiplexed i2c bus 3
[    2.758361] i2c i2c-2: Added multiplexed i2c bus 4
[    2.759065] i2c i2c-2: Added multiplexed i2c bus 5
[    2.759717] i2c i2c-2: Added multiplexed i2c bus 6
[    2.760392] i2c i2c-2: Added multiplexed i2c bus 7
[    2.761065] i2c i2c-2: Added multiplexed i2c bus 8
[    2.761081] pca954x 2-0077: registered 8 multiplexed busses for I2C switch 

...snipped...

[    2.951717] omap_i2c 44e0b000.i2c: failure adding adapter
...snipped...
[    2.964249] omap_i2c: probe of 44e0b000.i2c failed with error -16
... snipped ...
[    8.997764] cpu cpu0: of_pm_voltdm_notifier_register: Failed to get cpu0 regulator/voltdm: -517
[    8.997796] cpu cpu0: cpu0 clock notifier not ready, retry
[    9.082435] platform cpufreq-cpu0.0: Driver cpufreq-cpu0 requests probe deferral
[    9.194548] slave hdmi.38: could not get i2c  

Is there a quick work-around for this problem (prevent deferred probing or defer both bus probes)?

Is there a way that I can force the child buses to use names that don't conflict with BBB predefined buses (perhaps a property or alias in the device tree)?

Will the future "multiple i2c multiplexers on the same bus" solution fix this problem?

Any other ideas for a work around?

Regards,

Bob Feretich

I tried some random things and setting aliases in the dtsi file solved the problem. The use of an alias to set the name of an i2c bus should be documented somewhere!

<dtsi file fragment>

/ {
    aliases {
        i2c10 = &im0;
        i2c11 = &im1;
        i2c12 = &im2;
        i2c13 = &im3;
        i2c14 = &im4;
        i2c15 = &im5;
        i2c16 = &im6;
        i2c17 = &im7;
    };
};

&i2c0 {
    status = "okay";
};

&i2c2 {
    status = "okay";
    i2cmux@77 {
         compatible = "nxp,pca9548";
         #address-cells = <1>;
         #size-cells = <0>;
         reg = <0x77>;

 im0:    i2c-bus-0 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <0>;
        };
 im1:    i2c-bus-1 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <1>;
        };
 im2:    i2cm@2 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <2>;
        };
 im3:    i2cm@3 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <3>;
        };
 im4:    i2cm@4 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <4>;
        };
 im5:    i2cm@5 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <5>;
        };
 im6:    i2cm@6 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <6>;
        };
 im7:    i2cm@7 {
            #address-cells = <1>;
            #size-cells = <0>;
            reg = <7>;
        };
     };
};

*** Interactive commands *****

ubuntu@arm:~$ ls /dev/i2c*
/dev/i2c-0   /dev/i2c-11  /dev/i2c-13  /dev/i2c-15  /dev/i2c-17
/dev/i2c-10  /dev/i2c-12  /dev/i2c-14  /dev/i2c-16  /dev/i2c-2
ubuntu@arm:~$ i2cdetect -l
i2c-0    i2c           OMAP I2C adapter                    I2C adapter
i2c-2    i2c           OMAP I2C adapter                    I2C adapter
i2c-10    i2c           i2c-2-mux (chan_id 0)               I2C adapter
i2c-11    i2c           i2c-2-mux (chan_id 1)               I2C adapter
i2c-12    i2c           i2c-2-mux (chan_id 2)               I2C adapter
i2c-13    i2c           i2c-2-mux (chan_id 3)               I2C adapter
i2c-14    i2c           i2c-2-mux (chan_id 4)               I2C adapter
i2c-15    i2c           i2c-2-mux (chan_id 5)               I2C adapter
i2c-16    i2c           i2c-2-mux (chan_id 6)               I2C adapter
i2c-17    i2c           i2c-2-mux (chan_id 7)               I2C adapter
ubuntu@arm:~$ ls /sys/bus/i2c/devices
0-0024  0-0050  2-0054  2-0056  2-0077  i2c-10  i2c-12  i2c-14  i2c-16  i2c-2
0-0034  0-0070  2-0055  2-0057  i2c-0   i2c-11  i2c-13  i2c-15  i2c-17

Regards,
Bob Feretich

----- Original Message -----
From: Bob Feretich <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/[email protected]>; Guenter Roeck <[email protected]>; Bob Feretich <[email protected]>
Sent: Wednesday, March 11, 2015 9:11 PM
Subject: Another problem with I2C multiplexer bus naming

I am working on a BeagleBone Black (BBB) Cape that contains a PCA9548 multiplexer (mux). The BBB uses two I2C buses, i2c-0 for power management and i2c-2 for Cape discovery and other general use. I have created a dtsi file to describe the mux on my Cape per the Linux Documentation instructions.

...

&i2c2 {
    i2cmux@77 {
         compatible = "nxp,pca9548";
         #address-cells = <1>;
         #size-cells = <0>;
         reg = <0x77>;
};

...

When I boot Linux (3.14 kernel) without the cape attached I see i2c-0 and i2c-2...

ubuntu@arm:~$ ls /dev/i2* 
/dev/i2c-0  /dev/i2c-2
ubuntu@arm:~$ i2cdetect -l
i2c-0    i2c           OMAP I2C adapter                    I2C adapter
i2c-2    i2c           OMAP I2C adapter                    I2C adapter

But, I can also see in dmesg that i2c-0 probing is deferred until after i2c-2.

[    2.186756] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe
[    2.186803] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    2.193949] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
...snipped...
[    2.965899] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    2.967376] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    2.967500] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz

This causes a problem when I boot with the Cape attached.
1) Probing is deferred on i2c-0.
2) i2c-2 is probed, the mux is discovered, and the child buses are

    assigned i2c-0, i2c-1, and i2c-3 through i2c-8.

3) The original i2c-0 bus is then probed, but since it requires the name i2c-0 and that name is already used, adapter addition fails.

ubuntu@arm:~$ ls /dev/i2* 
/dev/i2c-0  /dev/i2c-2  /dev/i2c-4  /dev/i2c-6  /dev/i2c-8
/dev/i2c-1  /dev/i2c-3  /dev/i2c-5  /dev/i2c-7
ubuntu@arm:~$ i2cdetect -l
i2c-0    i2c           i2c-2-mux (chan_id 0)               I2C adapter
i2c-1    i2c           i2c-2-mux (chan_id 1)               I2C adapter
i2c-2    i2c           OMAP I2C adapter                    I2C adapter
i2c-3    i2c           i2c-2-mux (chan_id 2)               I2C adapter
i2c-4    i2c           i2c-2-mux (chan_id 3)               I2C adapter
i2c-5    i2c           i2c-2-mux (chan_id 4)               I2C adapter
i2c-6    i2c           i2c-2-mux (chan_id 5)               I2C adapter
i2c-7    i2c           i2c-2-mux (chan_id 6)               I2C adapter
i2c-8    i2c           i2c-2-mux (chan_id 7)               I2C adapter

[    2.186754] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe
[    2.186802] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral
[    2.193953] omap_i2c 4819c000.i2c: bus 2 rev0.11 at 100 kHz
...snipped...
[    2.753254] i2c /dev entries driver
[    2.756232] i2c i2c-2: Added multiplexed i2c bus 0
[    2.756992] i2c i2c-2: Added multiplexed i2c bus 1
[    2.757690] i2c i2c-2: Added multiplexed i2c bus 3
[    2.758361] i2c i2c-2: Added multiplexed i2c bus 4
[    2.759065] i2c i2c-2: Added multiplexed i2c bus 5
[    2.759717] i2c i2c-2: Added multiplexed i2c bus 6
[    2.760392] i2c i2c-2: Added multiplexed i2c bus 7
[    2.761065] i2c i2c-2: Added multiplexed i2c bus 8
[    2.761081] pca954x 2-0077: registered 8 multiplexed busses for I2C switch 

...snipped...

[    2.951717] omap_i2c 44e0b000.i2c: failure adding adapter
...snipped...
[    2.964249] omap_i2c: probe of 44e0b000.i2c failed with error -16
... snipped ...
[    8.997764] cpu cpu0: of_pm_voltdm_notifier_register: Failed to get cpu0 regulator/voltdm: -517
[    8.997796] cpu cpu0: cpu0 clock notifier not ready, retry
[    9.082435] platform cpufreq-cpu0.0: Driver cpufreq-cpu0 requests probe deferral
[    9.194548] slave hdmi.38: could not get i2c  

Is there a quick work-around for this problem (prevent deferred probing or defer both bus probes)?

Is there a way that I can force the child buses to use names that don't conflict with BBB predefined buses (perhaps a property or alias in the device tree)?

Will the future "multiple i2c multiplexers on the same bus" solution fix this problem?

Any other ideas for a work around?

Regards,

Bob Feretich
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Good.

Well, send a patch adding some documentation where you would have liked to see it.

Thanks,

Wolfram

The first two places I looked for information were:
* https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-mux.txt

This is where I found the info on specifying the multiplexer without aliases. It would seem logical to add the description of "how to explicitly name child buses" here.
* https://www.kernel.org/doc/Documentation/i2c/muxes/i2c-mux-gpio
Even though this file is for gpio controlled multiplexers, it seemed like a good spot to look for information on how to specify i2c multiplexers in general. It only describes the board.c method of registering adapters. (I don't know which gpio_i2cmux_platform_data fields would be the equivalent of specifying the device tree aliases.) Perhaps a cross-reference to the above documentation is appropriate, since use of customized board.c files is being discouraged.

Note that once device trees become dynamic and support hot plugging, the
alias bus naming solution becomes ineffective, unless there is a way to specify a hierarchical alias that references the bus/adapter id of the multiplexer.

Thanks,
Bob

Please do. You know best what kind of information you'd like to see there.

Send a patch and we will see :)

I2C was never considered hot-pluggable in the days. So, anyone wanting to use it this way needs to spend some effort adding it. Some steps have already been taken, though (e.g. dynamic of reconfig).

Try lsi2c on your system and see if the "PATHs" are unique.

on github: https://github.com/costad2/i2cdev

This should provide you with a unique and unchanging path for all of you i2c devices.

Then when the conflicting/inconsistent bus appears its path will not change even if its i2c-%d changes.

- Danielle

- Danielle Costantino

Thanks! After a first glimpse, this seems to be a bug. The omap driver uses i2c_add_numbered_adapter here in DT context, and thus __i2c_first_dynamic_bus_num is not properly increased because there is no static board_info. Will have a look.

I don't know what you are referring to here?

Regards,

Wolfram

Using non-DT becomes so rare that my knowledge about it gets rusty :(

Yes, one can't mix i2c_add_numbered_adapter and i2c_add_adapter well, and this is even documented. However, since you are DT only, this doesn't apply.

I don't know all of your dts files, but I assume there is already an alias for busses 0/2 somewhere?

I have not seen any documentation to regarding this topic.
I remember adding an i2c multiplexer to an early beagleboard system years ago. I think we were lucky that the fixed i2c bus addresses were probed first, so they were not stolen by the multiplexer's dynamic allocations. (Dynamic allocation does not steal bus addresses from previously allocated adapters.)

Yes, aliases for known buses and adapters are in /arch/arm/boot/dts/am33xx.dtsi
All of the cpu boards that use this chip include this file.

Although there is no documentation stating the effect that these aliases have, it gave me the idea to try to use them to name the multiplexer's child buses.

Other device documentation...
http://devicetree.org/Device_Tree_Usage#aliases_Node
describe an alias as a way to avoid "cumbersome" full path node names.
It also states, "The operating system is welcome to use the aliases when assigning an identifier to a device."

It would be useful also state that the i2c bus naming mechanism uses aliases to name i2c buses.

Thanks,
Bob

man i2c_add_numbered_adapter

...
* If no devices have pre-been declared for this bus, then be sure to
* register the adapter before any dynamically allocated ones. Otherwise
* the required bus ID may not be available.
...

I was just referring to it to express that this is known behaviour and not a bug like I first assumed.

You "need" a deferred probe for this clash to happen.

Care to send a patch? :)

And are you interested in testing the bugfix patches I sent around? I tested them locally, but verification from the bug-reporter is always good.

Thanks,

Wolfram

This patch extends the i2cmux description to document how i2c child bus numbers can be set from the device tree.

---

@@ -58,3 +58,78 @@ Example :
 			};
 		};
 	};
+
+The I2C subsystem will assign names to the child busses dynamically in
+the form i2c-n; where 'n' is an incrementing number starting with the
+number following the previously highest allocated bus number.
+
+Aliases may be used to assign static child bus names. The alias name
+must be of the form i2cnn where nn is numeric. The numeric part (nn) is
+used to set the bus number.
+
+Example :
+
+/ {
+	aliases {
+		i2c10 = &im0;
+		i2c11 = &im1;
+		i2c12 = &im2;
+		i2c13 = &im3;
+		i2c14 = &im4;
+		i2c15 = &im5;
+		i2c16 = &im6;
+		i2c17 = &im7;
+	};
+};
+...
+	i2cmux@70 {
+	 	compatible = "nxp,pca9548";
+	 	#address-cells = <1>;
+	 	#size-cells = <0>;
+	 	reg = <0x70>;
+
+ im0:	i2cm@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+		};
+ im1:	i2cm@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+		};
+ im2:	i2cm@2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+		};
+ im3:	i2cm@3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+		};
+ im4:	i2cm@4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <4>;
+		};
+ im5:	i2cm@5 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <5>;
+		};
+ im6:	i2cm@6 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <6>;
+		};
+ im7:	i2cm@7 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <7>;
+		};
+	 };
+
+The above file segment causes the child i2c busses to be named
+i2c-10 through i2c-17.
+