* Configuring device with I2C mux
@ 2020-01-08 1:13 Alex Qiu
2020-01-08 14:43 ` Milton Miller II
0 siblings, 1 reply; 8+ messages in thread
From: Alex Qiu @ 2020-01-08 1:13 UTC (permalink / raw)
To: OpenBMC Maillist; +Cc: Devjit Gopalpur, Kais Belgaied, Peter Lundgren
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
Hi folks,
We have a JSON file configuring I2C devices of a PCIe card which has an
8-channel I2C mux for entity-manager. After we properly configure the mux
of the card, we get 8 new I2C buses in sysfs; however, we don't find an
arithmetic way to describe the relationship between the new buses and their
parent buses.
For example, we have a mux on physical BMC I2C bus i2c-8 spawning a couple
of child buses including i2c-24 and i2c-26, which are the buses for each
PCIe card. The mux on i2c-24 PCIe card spawned 8 buses from i2c-70 to
i2c-77, and the mux on i2c-26 PCIe card spawned ones from i2c-62 to i2c-69.
We have I2C devices on i2c-76 and i2c-68 needs to be configured together
with the PCIe card on i2c-24 and i2c-26 separately.
How do we implement this in the JSON file? If that's not possible to do it
in JSON merely, what's the suggested approach to implement this feature?
Device tree? Implement code in entity-manager to walk through the I2C sysfs?
Thank you!
- Alex Qiu
[-- Attachment #2: Type: text/html, Size: 1256 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 1:13 Configuring device with I2C mux Alex Qiu
@ 2020-01-08 14:43 ` Milton Miller II
2020-01-08 17:25 ` Alex Qiu
0 siblings, 1 reply; 8+ messages in thread
From: Milton Miller II @ 2020-01-08 14:43 UTC (permalink / raw)
To: Alex Qiu; +Cc: OpenBMC Maillist, Peter Lundgren, Kais Belgaied, Devjit Gopalpur
About 01/07/2020 07:14PM in some timezone, Alex Qiu wrote:
>Hi folks,
>
>We have a JSON file configuring I2C devices of a PCIe card which has
>an 8-channel I2C mux for entity-manager. After we properly configure
>the mux of the card, we get 8 new I2C buses in sysfs; however, we
>don't find an arithmetic way to describe the relationship between the
>new buses and their parent buses.
>
>For example, we have a mux on physical BMC I2C bus i2c-8 spawning a
>couple of child buses including i2c-24 and i2c-26, which are the
>buses for each PCIe card. The mux on i2c-24 PCIe card spawned 8 buses
>from i2c-70 to i2c-77, and the mux on i2c-26 PCIe card spawned ones
>from i2c-62 to i2c-69. We have I2C devices on i2c-76 and i2c-68 needs
>to be configured together with the PCIe card on i2c-24 and i2c-26
>separately.
>
>How do we implement this in the JSON file? If that's not possible to
>do it in JSON merely, what's the suggested approach to implement this
>feature? Device tree? Implement code in entity-manager to walk
>through the I2C sysfs?
I would expect the i2c buses provied by the mux to appear in sysfs
under the hierarchy of the parent bus. Explore the sysfs directory
structure, I'm making this up, but I've now peeked at i2c-mux.c and
have a better chance getting reality.
/sys/bus/i2c/devices/i2c-8 -> /sys/devices/platform/ahb-432000/i2c-8
/sys/bus/i2c/devices/i2c-24 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
/sys/bus/i2c/devices/i2c-24 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
/sys/bus/i2c/devices/i2c-24 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
/sys/bus/i2c/devices/i2c-62 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-62
/sys/bus/i2c/devices/i2c-63 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-63
/sys/bus/i2c/devices/i2c-64 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-64
/sys/bus/i2c/devices/i2c-65 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-65
/sys/bus/i2c/devices/i2c-66 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-66
/sys/bus/i2c/devices/i2c-67 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-67
/sys/bus/i2c/devices/i2c-68 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-68
/sys/bus/i2c/devices/i2c-69 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-69
/sys/bus/i2c/devices/i2c-70 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-70
/sys/bus/i2c/devices/i2c-71 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-71
/sys/bus/i2c/devices/i2c-72 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-72
/sys/bus/i2c/devices/i2c-73 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-73
/sys/bus/i2c/devices/i2c-74 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-74
/sys/bus/i2c/devices/i2c-75 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-75
/sys/bus/i2c/devices/i2c-76 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-76
/sys/bus/i2c/devices/i2c-77 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-77
/sys/bus/i2c/devices/i2c-24/mux_device -> /sys/devices/platform/ahb-432000/i2c-8/8-52
/sys/bus/i2c/devices/i2c-25/mux_device -> /sys/devices/platform/ahb-432000/i2c-8/8-52
/sys/bus/i2c/devices/i2c-26/mux_device -> /sys/devices/platform/ahb-432000/i2c-8/8-52
/sys/bus/i2c/devices/8-52/channel-0 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
/sys/bus/i2c/devices/8-52/channel-1 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
/sys/bus/i2c/devices/8-52/channel-2 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
/sys/bus/i2c/devices/24-52/channel-0 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-62
/sys/bus/i2c/devices/24-52/channel-1 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-63
/sys/bus/i2c/devices/24-52/channel-2 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-64
/sys/bus/i2c/devices/24-52/channel-3 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-65
/sys/bus/i2c/devices/24-52/channel-4 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-66
/sys/bus/i2c/devices/24-52/channel-5 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-67
/sys/bus/i2c/devices/24-52/channel-6 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-68
/sys/bus/i2c/devices/24-52/channel-7 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-69
/sys/bus/i2c/devices/26-52/channel-0 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-70
/sys/bus/i2c/devices/26-52/channel-1 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-71
/sys/bus/i2c/devices/26-52/channel-2 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-72
/sys/bus/i2c/devices/26-52/channel-3 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-73
/sys/bus/i2c/devices/26-52/channel-4 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-74
/sys/bus/i2c/devices/26-52/channel-5 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-75
/sys/bus/i2c/devices/26-52/channel-6 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-76
/sys/bus/i2c/devices/26-52/channel-7 -> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-77
The child bus will have a symlink "mux_device" pointing to the mux.
The mux device node will have n symlinks "channel-1" where 1 is
the channel id.
Hmm, there is no apparent code to put a "mux_channel" attribute in
the adapter node. The adapter name attribute does include the channel
id, but its long descriptive text. Regardless, you should be able to
find the buses from the mux channel-3 symlinks.
Note: I haven't looked at the JSON to see how much it will change once
your find the bus. I'm guessing you will have to generate it by taking
a template and substituting the bus numbers you find to make the slots
common, alhtough you could just go from the 8-52/channel-3 symlink to
the adapter bus (the device name will still have the bus number in it).
I hope this helps you,
milton
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 14:43 ` Milton Miller II
@ 2020-01-08 17:25 ` Alex Qiu
2020-01-08 17:46 ` James Feist
0 siblings, 1 reply; 8+ messages in thread
From: Alex Qiu @ 2020-01-08 17:25 UTC (permalink / raw)
To: Milton Miller II
Cc: OpenBMC Maillist, Peter Lundgren, Kais Belgaied, Devjit Gopalpur
[-- Attachment #1: Type: text/plain, Size: 6728 bytes --]
Hi Milton,
Yes, the child buses are traceable in the sysfs, but actually my question
is, does entity-manager supports tracing child buses through the sysfs? If
it does, how shall I write the JSON config to take advantage of this
feature?
For example, we have a I2C device sitting at the same level as the mux,
configured as {"Address": "0x40", "Bus": "$bus"}, and now I don't find the
way to add or subtract a certain number to $bus to find a child bus. Do we
have a feature with syntax like {"Address": "0x50", "Bus":
"$bus.mux.0x70.channel.1"} to configure devices on child buses, with mux
sitting on 0x70 of the parent bus?
Thank you!
- Alex Qiu
On Wed, Jan 8, 2020 at 6:43 AM Milton Miller II <miltonm@us.ibm.com> wrote:
> About 01/07/2020 07:14PM in some timezone, Alex Qiu wrote:
> >Hi folks,
> >
> >We have a JSON file configuring I2C devices of a PCIe card which has
> >an 8-channel I2C mux for entity-manager. After we properly configure
> >the mux of the card, we get 8 new I2C buses in sysfs; however, we
> >don't find an arithmetic way to describe the relationship between the
> >new buses and their parent buses.
> >
> >For example, we have a mux on physical BMC I2C bus i2c-8 spawning a
> >couple of child buses including i2c-24 and i2c-26, which are the
> >buses for each PCIe card. The mux on i2c-24 PCIe card spawned 8 buses
> >from i2c-70 to i2c-77, and the mux on i2c-26 PCIe card spawned ones
> >from i2c-62 to i2c-69. We have I2C devices on i2c-76 and i2c-68 needs
> >to be configured together with the PCIe card on i2c-24 and i2c-26
> >separately.
> >
> >How do we implement this in the JSON file? If that's not possible to
> >do it in JSON merely, what's the suggested approach to implement this
> >feature? Device tree? Implement code in entity-manager to walk
> >through the I2C sysfs?
>
>
> I would expect the i2c buses provied by the mux to appear in sysfs
> under the hierarchy of the parent bus. Explore the sysfs directory
> structure, I'm making this up, but I've now peeked at i2c-mux.c and
> have a better chance getting reality.
>
>
> /sys/bus/i2c/devices/i2c-8 -> /sys/devices/platform/ahb-432000/i2c-8
>
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
>
> /sys/bus/i2c/devices/i2c-62 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-62
> /sys/bus/i2c/devices/i2c-63 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-63
> /sys/bus/i2c/devices/i2c-64 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-64
> /sys/bus/i2c/devices/i2c-65 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-65
> /sys/bus/i2c/devices/i2c-66 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-66
> /sys/bus/i2c/devices/i2c-67 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-67
> /sys/bus/i2c/devices/i2c-68 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-68
> /sys/bus/i2c/devices/i2c-69 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-69
> /sys/bus/i2c/devices/i2c-70 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-70
> /sys/bus/i2c/devices/i2c-71 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-71
> /sys/bus/i2c/devices/i2c-72 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-72
> /sys/bus/i2c/devices/i2c-73 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-73
> /sys/bus/i2c/devices/i2c-74 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-74
> /sys/bus/i2c/devices/i2c-75 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-75
> /sys/bus/i2c/devices/i2c-76 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-76
> /sys/bus/i2c/devices/i2c-77 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-77
>
> /sys/bus/i2c/devices/i2c-24/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
> /sys/bus/i2c/devices/i2c-25/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
> /sys/bus/i2c/devices/i2c-26/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
>
> /sys/bus/i2c/devices/8-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> /sys/bus/i2c/devices/8-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> /sys/bus/i2c/devices/8-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
>
> /sys/bus/i2c/devices/24-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-62
> /sys/bus/i2c/devices/24-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-63
> /sys/bus/i2c/devices/24-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-64
> /sys/bus/i2c/devices/24-52/channel-3 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-65
> /sys/bus/i2c/devices/24-52/channel-4 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-66
> /sys/bus/i2c/devices/24-52/channel-5 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-67
> /sys/bus/i2c/devices/24-52/channel-6 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-68
> /sys/bus/i2c/devices/24-52/channel-7 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-69
> /sys/bus/i2c/devices/26-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-70
> /sys/bus/i2c/devices/26-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-71
> /sys/bus/i2c/devices/26-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-72
> /sys/bus/i2c/devices/26-52/channel-3 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-73
> /sys/bus/i2c/devices/26-52/channel-4 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-74
> /sys/bus/i2c/devices/26-52/channel-5 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-75
> /sys/bus/i2c/devices/26-52/channel-6 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-76
> /sys/bus/i2c/devices/26-52/channel-7 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-77
>
> The child bus will have a symlink "mux_device" pointing to the mux.
> The mux device node will have n symlinks "channel-1" where 1 is
> the channel id.
>
> Hmm, there is no apparent code to put a "mux_channel" attribute in
> the adapter node. The adapter name attribute does include the channel
> id, but its long descriptive text. Regardless, you should be able to
> find the buses from the mux channel-3 symlinks.
>
> Note: I haven't looked at the JSON to see how much it will change once
> your find the bus. I'm guessing you will have to generate it by taking
> a template and substituting the bus numbers you find to make the slots
> common, alhtough you could just go from the 8-52/channel-3 symlink to
> the adapter bus (the device name will still have the bus number in it).
>
> I hope this helps you,
>
> milton
>
>
[-- Attachment #2: Type: text/html, Size: 7776 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 17:25 ` Alex Qiu
@ 2020-01-08 17:46 ` James Feist
2020-01-08 17:54 ` Alex Qiu
0 siblings, 1 reply; 8+ messages in thread
From: James Feist @ 2020-01-08 17:46 UTC (permalink / raw)
To: Alex Qiu, Milton Miller II
Cc: Peter Lundgren, OpenBMC Maillist, Kais Belgaied, Devjit Gopalpur
On 1/8/20 9:25 AM, Alex Qiu wrote:
> Hi Milton,
>
> Yes, the child buses are traceable in the sysfs, but actually my
> question is, does entity-manager supports tracing child buses through
> the sysfs? If it does, how shall I write the JSON config to take
> advantage of this feature?
>
> For example, we have a I2C device sitting at the same level as the mux,
> configured as {"Address": "0x40", "Bus": "$bus"}, and now I don't find
> the way to add or subtract a certain number to $bus to find a child bus.
> Do we have a feature with syntax like {"Address": "0x50", "Bus":
> "$bus.mux.0x70.channel.1"} to configure devices on child buses, with mux
> sitting on 0x70 of the parent bus?
Do you have a device sitting behind the mux? Generally in most our
situations we have another FRU behind the mux, and we can use "$bus" to
describe this.
Second option is you can name the mux channels, like this:
https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/configurations/WFT%20Baseboard.json#L1023
And then in /dev/ you'll get symlinks like this:
root@intel-obmc:~# ls -al /dev/i2c-mux/M2_Mux/
drwxr-xr-x 2 root root 80 Jan 1 00:01 .
drwxr-xr-x 9 root root 180 Jan 1 00:01 ..
lrwxrwxrwx 1 root root 11 Jan 1 00:01 M2Slot1 ->
/dev/i2c-14
lrwxrwxrwx 1 root root 11 Jan 1 00:01 M2Slot2 ->
/dev/i2c-15
-James
>
> Thank you!
>
> - Alex Qiu
>
>
> On Wed, Jan 8, 2020 at 6:43 AM Milton Miller II <miltonm@us.ibm.com
> <mailto:miltonm@us.ibm.com>> wrote:
>
> About 01/07/2020 07:14PM in some timezone, Alex Qiu wrote:
> >Hi folks,
> >
> >We have a JSON file configuring I2C devices of a PCIe card which has
> >an 8-channel I2C mux for entity-manager. After we properly configure
> >the mux of the card, we get 8 new I2C buses in sysfs; however, we
> >don't find an arithmetic way to describe the relationship between the
> >new buses and their parent buses.
> >
> >For example, we have a mux on physical BMC I2C bus i2c-8 spawning a
> >couple of child buses including i2c-24 and i2c-26, which are the
> >buses for each PCIe card. The mux on i2c-24 PCIe card spawned 8 buses
> >from i2c-70 to i2c-77, and the mux on i2c-26 PCIe card spawned ones
> >from i2c-62 to i2c-69. We have I2C devices on i2c-76 and i2c-68 needs
> >to be configured together with the PCIe card on i2c-24 and i2c-26
> >separately.
> >
> >How do we implement this in the JSON file? If that's not possible to
> >do it in JSON merely, what's the suggested approach to implement this
> >feature? Device tree? Implement code in entity-manager to walk
> >through the I2C sysfs?
>
>
> I would expect the i2c buses provied by the mux to appear in sysfs
> under the hierarchy of the parent bus. Explore the sysfs directory
> structure, I'm making this up, but I've now peeked at i2c-mux.c and
> have a better chance getting reality.
>
>
> /sys/bus/i2c/devices/i2c-8 -> /sys/devices/platform/ahb-432000/i2c-8
>
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> /sys/bus/i2c/devices/i2c-24 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
>
> /sys/bus/i2c/devices/i2c-62 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-62
> /sys/bus/i2c/devices/i2c-63 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-63
> /sys/bus/i2c/devices/i2c-64 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-64
> /sys/bus/i2c/devices/i2c-65 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-65
> /sys/bus/i2c/devices/i2c-66 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-66
> /sys/bus/i2c/devices/i2c-67 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-67
> /sys/bus/i2c/devices/i2c-68 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-68
> /sys/bus/i2c/devices/i2c-69 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-69
> /sys/bus/i2c/devices/i2c-70 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-70
> /sys/bus/i2c/devices/i2c-71 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-71
> /sys/bus/i2c/devices/i2c-72 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-72
> /sys/bus/i2c/devices/i2c-73 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-73
> /sys/bus/i2c/devices/i2c-74 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-74
> /sys/bus/i2c/devices/i2c-75 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-75
> /sys/bus/i2c/devices/i2c-76 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-76
> /sys/bus/i2c/devices/i2c-77 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-77
>
> /sys/bus/i2c/devices/i2c-24/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
> /sys/bus/i2c/devices/i2c-25/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
> /sys/bus/i2c/devices/i2c-26/mux_device ->
> /sys/devices/platform/ahb-432000/i2c-8/8-52
>
> /sys/bus/i2c/devices/8-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> /sys/bus/i2c/devices/8-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> /sys/bus/i2c/devices/8-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26
>
> /sys/bus/i2c/devices/24-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-62
> /sys/bus/i2c/devices/24-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-63
> /sys/bus/i2c/devices/24-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-64
> /sys/bus/i2c/devices/24-52/channel-3 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-65
> /sys/bus/i2c/devices/24-52/channel-4 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-66
> /sys/bus/i2c/devices/24-52/channel-5 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-67
> /sys/bus/i2c/devices/24-52/channel-6 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-68
> /sys/bus/i2c/devices/24-52/channel-7 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-69
> /sys/bus/i2c/devices/26-52/channel-0 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-70
> /sys/bus/i2c/devices/26-52/channel-1 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-71
> /sys/bus/i2c/devices/26-52/channel-2 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-72
> /sys/bus/i2c/devices/26-52/channel-3 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-73
> /sys/bus/i2c/devices/26-52/channel-4 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-74
> /sys/bus/i2c/devices/26-52/channel-5 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-75
> /sys/bus/i2c/devices/26-52/channel-6 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-76
> /sys/bus/i2c/devices/26-52/channel-7 ->
> /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-77
>
> The child bus will have a symlink "mux_device" pointing to the mux.
> The mux device node will have n symlinks "channel-1" where 1 is
> the channel id.
>
> Hmm, there is no apparent code to put a "mux_channel" attribute in
> the adapter node. The adapter name attribute does include the channel
> id, but its long descriptive text. Regardless, you should be able to
> find the buses from the mux channel-3 symlinks.
>
> Note: I haven't looked at the JSON to see how much it will change once
> your find the bus. I'm guessing you will have to generate it by taking
> a template and substituting the bus numbers you find to make the slots
> common, alhtough you could just go from the 8-52/channel-3 symlink to
> the adapter bus (the device name will still have the bus number in it).
>
> I hope this helps you,
>
> milton
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 17:46 ` James Feist
@ 2020-01-08 17:54 ` Alex Qiu
2020-01-08 18:02 ` James Feist
0 siblings, 1 reply; 8+ messages in thread
From: Alex Qiu @ 2020-01-08 17:54 UTC (permalink / raw)
To: James Feist
Cc: Milton Miller II, Peter Lundgren, OpenBMC Maillist,
Kais Belgaied, Devjit Gopalpur
[-- Attachment #1: Type: text/plain, Size: 8968 bytes --]
Hi James,
Yes, we have multiple devices sitting behind the mux, and they're onboard
devices instead of standalone FRUs. The parent bus is described as the FRU
for each PCIe card.
After naming the mux channels, can these names be used somehow to config
I2C devices? For example, {"Bus": "$bus", "ChannelNames":
["C0", "C1", "C2", "C3"]} for the mux, and {"Bus": "$bus.C1"} for devices
behind the mux on channel 1.
Thanks!
- Alex Qiu
On Wed, Jan 8, 2020 at 9:47 AM James Feist <james.feist@linux.intel.com>
wrote:
> On 1/8/20 9:25 AM, Alex Qiu wrote:
> > Hi Milton,
> >
> > Yes, the child buses are traceable in the sysfs, but actually my
> > question is, does entity-manager supports tracing child buses through
> > the sysfs? If it does, how shall I write the JSON config to take
> > advantage of this feature?
> >
> > For example, we have a I2C device sitting at the same level as the mux,
> > configured as {"Address": "0x40", "Bus": "$bus"}, and now I don't find
> > the way to add or subtract a certain number to $bus to find a child bus.
> > Do we have a feature with syntax like {"Address": "0x50", "Bus":
> > "$bus.mux.0x70.channel.1"} to configure devices on child buses, with mux
> > sitting on 0x70 of the parent bus?
>
> Do you have a device sitting behind the mux? Generally in most our
> situations we have another FRU behind the mux, and we can use "$bus" to
> describe this.
>
> Second option is you can name the mux channels, like this:
>
> https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/configurations/WFT%20Baseboard.json#L1023
>
> And then in /dev/ you'll get symlinks like this:
>
> root@intel-obmc:~# ls -al /dev/i2c-mux/M2_Mux/
> drwxr-xr-x 2 root root 80 Jan 1 00:01 .
> drwxr-xr-x 9 root root 180 Jan 1 00:01 ..
> lrwxrwxrwx 1 root root 11 Jan 1 00:01 M2Slot1 ->
> /dev/i2c-14
> lrwxrwxrwx 1 root root 11 Jan 1 00:01 M2Slot2 ->
> /dev/i2c-15
>
> -James
>
>
> >
> > Thank you!
> >
> > - Alex Qiu
> >
> >
> > On Wed, Jan 8, 2020 at 6:43 AM Milton Miller II <miltonm@us.ibm.com
> > <mailto:miltonm@us.ibm.com>> wrote:
> >
> > About 01/07/2020 07:14PM in some timezone, Alex Qiu wrote:
> > >Hi folks,
> > >
> > >We have a JSON file configuring I2C devices of a PCIe card which
> has
> > >an 8-channel I2C mux for entity-manager. After we properly
> configure
> > >the mux of the card, we get 8 new I2C buses in sysfs; however, we
> > >don't find an arithmetic way to describe the relationship between
> the
> > >new buses and their parent buses.
> > >
> > >For example, we have a mux on physical BMC I2C bus i2c-8 spawning a
> > >couple of child buses including i2c-24 and i2c-26, which are the
> > >buses for each PCIe card. The mux on i2c-24 PCIe card spawned 8
> buses
> > >from i2c-70 to i2c-77, and the mux on i2c-26 PCIe card spawned ones
> > >from i2c-62 to i2c-69. We have I2C devices on i2c-76 and i2c-68
> needs
> > >to be configured together with the PCIe card on i2c-24 and i2c-26
> > >separately.
> > >
> > >How do we implement this in the JSON file? If that's not possible
> to
> > >do it in JSON merely, what's the suggested approach to implement
> this
> > >feature? Device tree? Implement code in entity-manager to walk
> > >through the I2C sysfs?
> >
> >
> > I would expect the i2c buses provied by the mux to appear in sysfs
> > under the hierarchy of the parent bus. Explore the sysfs directory
> > structure, I'm making this up, but I've now peeked at i2c-mux.c and
> > have a better chance getting reality.
> >
> >
> > /sys/bus/i2c/devices/i2c-8 -> /sys/devices/platform/ahb-432000/i2c-8
> >
> > /sys/bus/i2c/devices/i2c-24 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> > /sys/bus/i2c/devices/i2c-24 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> > /sys/bus/i2c/devices/i2c-24 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26
> >
> > /sys/bus/i2c/devices/i2c-62 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-62
> > /sys/bus/i2c/devices/i2c-63 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-63
> > /sys/bus/i2c/devices/i2c-64 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-64
> > /sys/bus/i2c/devices/i2c-65 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-65
> > /sys/bus/i2c/devices/i2c-66 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-66
> > /sys/bus/i2c/devices/i2c-67 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-67
> > /sys/bus/i2c/devices/i2c-68 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-68
> > /sys/bus/i2c/devices/i2c-69 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-69
> > /sys/bus/i2c/devices/i2c-70 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-70
> > /sys/bus/i2c/devices/i2c-71 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-71
> > /sys/bus/i2c/devices/i2c-72 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-72
> > /sys/bus/i2c/devices/i2c-73 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-73
> > /sys/bus/i2c/devices/i2c-74 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-74
> > /sys/bus/i2c/devices/i2c-75 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-75
> > /sys/bus/i2c/devices/i2c-76 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-76
> > /sys/bus/i2c/devices/i2c-77 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-77
> >
> > /sys/bus/i2c/devices/i2c-24/mux_device ->
> > /sys/devices/platform/ahb-432000/i2c-8/8-52
> > /sys/bus/i2c/devices/i2c-25/mux_device ->
> > /sys/devices/platform/ahb-432000/i2c-8/8-52
> > /sys/bus/i2c/devices/i2c-26/mux_device ->
> > /sys/devices/platform/ahb-432000/i2c-8/8-52
> >
> > /sys/bus/i2c/devices/8-52/channel-0 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24
> > /sys/bus/i2c/devices/8-52/channel-1 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-25
> > /sys/bus/i2c/devices/8-52/channel-2 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26
> >
> > /sys/bus/i2c/devices/24-52/channel-0 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-62
> > /sys/bus/i2c/devices/24-52/channel-1 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-63
> > /sys/bus/i2c/devices/24-52/channel-2 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-64
> > /sys/bus/i2c/devices/24-52/channel-3 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-65
> > /sys/bus/i2c/devices/24-52/channel-4 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-66
> > /sys/bus/i2c/devices/24-52/channel-5 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-67
> > /sys/bus/i2c/devices/24-52/channel-6 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-68
> > /sys/bus/i2c/devices/24-52/channel-7 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-24/i2c-69
> > /sys/bus/i2c/devices/26-52/channel-0 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-70
> > /sys/bus/i2c/devices/26-52/channel-1 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-71
> > /sys/bus/i2c/devices/26-52/channel-2 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-72
> > /sys/bus/i2c/devices/26-52/channel-3 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-73
> > /sys/bus/i2c/devices/26-52/channel-4 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-74
> > /sys/bus/i2c/devices/26-52/channel-5 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-75
> > /sys/bus/i2c/devices/26-52/channel-6 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-76
> > /sys/bus/i2c/devices/26-52/channel-7 ->
> > /sys/devices/platform/ahb-432000/i2c-8/i2c-26/i2c-77
> >
> > The child bus will have a symlink "mux_device" pointing to the mux.
> > The mux device node will have n symlinks "channel-1" where 1 is
> > the channel id.
> >
> > Hmm, there is no apparent code to put a "mux_channel" attribute in
> > the adapter node. The adapter name attribute does include the
> channel
> > id, but its long descriptive text. Regardless, you should be able to
> > find the buses from the mux channel-3 symlinks.
> >
> > Note: I haven't looked at the JSON to see how much it will change
> once
> > your find the bus. I'm guessing you will have to generate it by
> taking
> > a template and substituting the bus numbers you find to make the
> slots
> > common, alhtough you could just go from the 8-52/channel-3 symlink to
> > the adapter bus (the device name will still have the bus number in
> it).
> >
> > I hope this helps you,
> >
> > milton
> >
>
[-- Attachment #2: Type: text/html, Size: 11667 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 17:54 ` Alex Qiu
@ 2020-01-08 18:02 ` James Feist
2020-01-08 18:06 ` Alex Qiu
0 siblings, 1 reply; 8+ messages in thread
From: James Feist @ 2020-01-08 18:02 UTC (permalink / raw)
To: Alex Qiu
Cc: Milton Miller II, Peter Lundgren, OpenBMC Maillist,
Kais Belgaied, Devjit Gopalpur
On 1/8/20 9:54 AM, Alex Qiu wrote:
> Hi James,
>
> Yes, we have multiple devices sitting behind the mux, and they're
> onboard devices instead of standalone FRUs. The parent bus is described
> as the FRU for each PCIe card.
>
> After naming the mux channels, can these names be used somehow to config
> I2C devices? For example, {"Bus": "$bus", "ChannelNames":
> ["C0", "C1", "C2", "C3"]} for the mux, and {"Bus": "$bus.C1"} for
> devices behind the mux on channel 1.
This syntax doesn't exist today.. On all our systems things behind the
mux are again detectable, so we haven't hit this problem. Right now the
template replacement is purely based on the found device on d-bus. So
$bus is the bus property from the xyz.openbmc_project.FruDevice
interface, there's no way to trace that to a mux channel, as it's just a
d-bus property.
The code you're looking for is here:
https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Utils.cpp#L144
Along with the channel identification logic here:
https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Overlay.cpp#L112
You could probably add some special syntax to make this work. Luckily
this is the one part of entity-manager that is unit-tested, so that
should help you
https://github.com/openbmc/entity-manager/blob/master/test/test_entity-manager.cpp
-James
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 18:02 ` James Feist
@ 2020-01-08 18:06 ` Alex Qiu
2020-01-10 1:46 ` Alex Qiu
0 siblings, 1 reply; 8+ messages in thread
From: Alex Qiu @ 2020-01-08 18:06 UTC (permalink / raw)
To: James Feist
Cc: Milton Miller II, Peter Lundgren, OpenBMC Maillist,
Kais Belgaied, Devjit Gopalpur
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
Hi James,
I'll take a look at them. Thanks for pointing the related code out!
- Alex Qiu
On Wed, Jan 8, 2020 at 10:02 AM James Feist <james.feist@linux.intel.com>
wrote:
> On 1/8/20 9:54 AM, Alex Qiu wrote:
> > Hi James,
> >
> > Yes, we have multiple devices sitting behind the mux, and they're
> > onboard devices instead of standalone FRUs. The parent bus is described
> > as the FRU for each PCIe card.
> >
> > After naming the mux channels, can these names be used somehow to config
> > I2C devices? For example, {"Bus": "$bus", "ChannelNames":
> > ["C0", "C1", "C2", "C3"]} for the mux, and {"Bus": "$bus.C1"} for
> > devices behind the mux on channel 1.
>
> This syntax doesn't exist today.. On all our systems things behind the
> mux are again detectable, so we haven't hit this problem. Right now the
> template replacement is purely based on the found device on d-bus. So
> $bus is the bus property from the xyz.openbmc_project.FruDevice
> interface, there's no way to trace that to a mux channel, as it's just a
> d-bus property.
>
> The code you're looking for is here:
>
> https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Utils.cpp#L144
>
>
> Along with the channel identification logic here:
>
> https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Overlay.cpp#L112
>
> You could probably add some special syntax to make this work. Luckily
> this is the one part of entity-manager that is unit-tested, so that
> should help you
>
> https://github.com/openbmc/entity-manager/blob/master/test/test_entity-manager.cpp
>
>
> -James
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2810 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Configuring device with I2C mux
2020-01-08 18:06 ` Alex Qiu
@ 2020-01-10 1:46 ` Alex Qiu
0 siblings, 0 replies; 8+ messages in thread
From: Alex Qiu @ 2020-01-10 1:46 UTC (permalink / raw)
To: James Feist
Cc: Milton Miller II, Peter Lundgren, OpenBMC Maillist,
Kais Belgaied, Devjit Gopalpur
[-- Attachment #1: Type: text/plain, Size: 2026 bytes --]
Hi folks,
Thanks for your responses! We managed to configure them by setting up the
device tree, fixing the child buses to numbers related to the parent buses,
so that we could address them using simple arithmetic operations in JSON
config files.
- Alex Qiu
On Wed, Jan 8, 2020 at 10:06 AM Alex Qiu <xqiu@google.com> wrote:
> Hi James,
>
> I'll take a look at them. Thanks for pointing the related code out!
>
> - Alex Qiu
>
>
> On Wed, Jan 8, 2020 at 10:02 AM James Feist <james.feist@linux.intel.com>
> wrote:
>
>> On 1/8/20 9:54 AM, Alex Qiu wrote:
>> > Hi James,
>> >
>> > Yes, we have multiple devices sitting behind the mux, and they're
>> > onboard devices instead of standalone FRUs. The parent bus is described
>> > as the FRU for each PCIe card.
>> >
>> > After naming the mux channels, can these names be used somehow to
>> config
>> > I2C devices? For example, {"Bus": "$bus", "ChannelNames":
>> > ["C0", "C1", "C2", "C3"]} for the mux, and {"Bus": "$bus.C1"} for
>> > devices behind the mux on channel 1.
>>
>> This syntax doesn't exist today.. On all our systems things behind the
>> mux are again detectable, so we haven't hit this problem. Right now the
>> template replacement is purely based on the found device on d-bus. So
>> $bus is the bus property from the xyz.openbmc_project.FruDevice
>> interface, there's no way to trace that to a mux channel, as it's just a
>> d-bus property.
>>
>> The code you're looking for is here:
>>
>> https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Utils.cpp#L144
>>
>>
>> Along with the channel identification logic here:
>>
>> https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Overlay.cpp#L112
>>
>> You could probably add some special syntax to make this work. Luckily
>> this is the one part of entity-manager that is unit-tested, so that
>> should help you
>>
>> https://github.com/openbmc/entity-manager/blob/master/test/test_entity-manager.cpp
>>
>>
>> -James
>>
>>
>>
>>
>>
[-- Attachment #2: Type: text/html, Size: 3535 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-10 1:47 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08 1:13 Configuring device with I2C mux Alex Qiu
2020-01-08 14:43 ` Milton Miller II
2020-01-08 17:25 ` Alex Qiu
2020-01-08 17:46 ` James Feist
2020-01-08 17:54 ` Alex Qiu
2020-01-08 18:02 ` James Feist
2020-01-08 18:06 ` Alex Qiu
2020-01-10 1:46 ` Alex Qiu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.