Another problem with I2C multiplexer bus naming

Another problem with I2C multiplexer bus naming

[Bob Feretich]

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


>From dmesg...
[    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

Re: Another problem with I2C multiplexer bus naming - solved

[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 <bob.feretich-8wbKi1faPaosQv5ZqcSHkQ@public.gmane.org>
To: "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>; Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>; Bob Feretich <bob.feretich-8wbKi1faPaosQv5ZqcSHkQ@public.gmane.org>
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


>From dmesg...
[    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Another problem with I2C multiplexer bus naming - solved

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

On Wed, Mar 11, 2015 at 09:55:51PM -0700, Bob Feretich wrote:

> I tried some random things and setting aliases in the dtsi file solved
> the problem.

Good.

> The use of an alias to set the name of an i2c bus should
> be documented somewhere!

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

Thanks,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Another problem with I2C multiplexer bus naming - solved

[Bob Feretich]

On 3/12/2015 2:44 AM, Wolfram Sang wrote:
> On Wed, Mar 11, 2015 at 09:55:51PM -0700, Bob Feretich wrote:
>
>> I tried some random things and setting aliases in the dtsi file solved
>> the problem.
>
> Good.
>
>> The use of an alias to set the name of an i2c bus should
>> be documented somewhere!
>
> 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

Re: Another problem with I2C multiplexer bus naming - solved

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

On Thu, Mar 12, 2015 at 11:49:48AM -0700, Bob Feretich wrote:
> On 3/12/2015 2:44 AM, Wolfram Sang wrote:
> >On Wed, Mar 11, 2015 at 09:55:51PM -0700, Bob Feretich wrote:
> >
> >>I tried some random things and setting aliases in the dtsi file solved
> >>the problem.
> >
> >Good.
> >
> >>The use of an alias to set the name of an i2c bus should
> >>be documented somewhere!
> >
> >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.

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

> * 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.

Send a patch and we will see :)

> 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.

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).


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Another problem with I2C multiplexer bus naming

[Danielle Costantino]

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


On Wed, Mar 11, 2015 at 9:11 PM, Bob Feretich
<bob.feretich-8wbKi1faPaosQv5ZqcSHkQ@public.gmane.org> wrote:
> 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
>
>
> From dmesg...
> [    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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
- Danielle Costantino

Re: Another problem with I2C multiplexer bus naming

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]


> [    2.951717] omap_i2c 44e0b000.i2c: failure adding adapter
> ...snipped...
> [    2.964249] omap_i2c: probe of 44e0b000.i2c failed with error -16
> ... snipped ...

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.

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

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

Regards,

   Wolfram

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Another problem with I2C multiplexer bus naming

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On Thu, Mar 12, 2015 at 10:42:27AM +0100, Wolfram Sang wrote:
> 
> > [    2.951717] omap_i2c 44e0b000.i2c: failure adding adapter
> > ...snipped...
> > [    2.964249] omap_i2c: probe of 44e0b000.i2c failed with error -16
> > ... snipped ...
> 
> 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.

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?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Another problem with I2C multiplexer bus naming

[Bob Feretich]

On 3/12/2015 4:29 AM, Wolfram Sang wrote:
> On Thu, Mar 12, 2015 at 10:42:27AM +0100, Wolfram Sang wrote:
>>
>>> [    2.951717] omap_i2c 44e0b000.i2c: failure adding adapter
>>> ...snipped...
>>> [    2.964249] omap_i2c: probe of 44e0b000.i2c failed with error -16
>>> ... snipped ...
>>
>> 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.
>
> 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 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.)

> I don't know all of your dts files, but I assume there is already an
> alias for busses 0/2 somewhere?
>
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

Re: Another problem with I2C multiplexer bus naming

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]


> >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 have not seen any documentation to regarding this topic.

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.

> 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.

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

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

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


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 1/1] i2c: documentation of how to set child bus numbers from the device tree

[Bob Feretich]

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

Signed-off-by: Bob Feretich <bob.feretich-8wbKi1faPaosQv5ZqcSHkQ@public.gmane.org>
---
--- a/Documentation/devicetree/bindings/i2c/i2c-mux.txt	2015-05-07 
13:27:32.571371080 -0700
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux.txt	2015-05-07 
13:31:58.699044026 -0700
@@ -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.
+