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