Update the GPIO linename of each PDB CPLD IO expander based on latest
CPLD firmware.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
---
.../dts/aspeed/aspeed-bmc-facebook-catalina.dts | 99 +++++++---------------
1 file changed, 29 insertions(+), 70 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-catalina.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-catalina.dts
index 82835e96317d..10a9fca1b803 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-catalina.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-catalina.dts
@@ -802,26 +802,6 @@ io_expander12: gpio@13 {
gpio-controller;
#gpio-cells = <2>;
};
-
- // PDB CPLD IOEXP 0x14
- io_expander13: gpio@14 {
- compatible = "nxp,pca9555";
- interrupt-parent = <&gpio0>;
- interrupts = <ASPEED_GPIO(I, 6) IRQ_TYPE_LEVEL_LOW>;
- reg = <0x14>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
- // PDB CPLD IOEXP 0x15
- io_expander14: gpio@15 {
- compatible = "nxp,pca9555";
- interrupt-parent = <&gpio0>;
- interrupts = <ASPEED_GPIO(I, 6) IRQ_TYPE_LEVEL_LOW>;
- reg = <0x15>;
- gpio-controller;
- #gpio-cells = <2>;
- };
};
&i2c15 {
@@ -1040,71 +1020,50 @@ &io_expander8 {
&io_expander9 {
gpio-line-names =
- "LEAK3_DETECT_R","LEAK1_DETECT_R",
- "LEAK2_DETECT_R","LEAK0_DETECT_R",
- "CHASSIS3_LEAK_Q_N_PLD","CHASSIS1_LEAK_Q_N_PLD",
- "CHASSIS2_LEAK_Q_N_PLD","CHASSIS0_LEAK_Q_N_PLD",
- "P12V_AUX_FAN_ALERT_PLD_N","P12V_AUX_FAN_OC_PLD_N",
- "P12V_AUX_FAN_FAULT_PLD_N","LEAK_DETECT_RMC_N_R",
- "RSVD_RMC_GPIO3_R","SMB_RJ45_FIO_TMP_ALERT",
- "","";
+ "wSequence_Latch_State_N","wP12V_N1N2_RUNTIME_FLT_N",
+ "wP12V_FAN_RUNTIME_FLT_N","wP12V_AUX_RUNTIME_FLT_N",
+ "wHost_PERST_SEQPWR_FLT_N","wP12V_N1N2_SEQPWR_FLT_N",
+ "wP12V_FAN_SEQPWR_FLT_N","wP12V_AUX_SEQPWR_FLT_N",
+ "wP12V_RUNTIME_FLT_NIC1_N","wAUX_RUNTIME_FLT_NIC1_N",
+ "wP12V_SEQPWR_FLT_NIC1_N","wAUX_SEQPWR_FLT_NIC1_N",
+ "wP12V_RUNTIME_FLT_NIC0_N","wAUX_RUNTIME_FLT_NIC0_N",
+ "wP12V_SEQPWR_FLT_NIC0_N","wAUX_SEQPWR_FLT_NIC0_N";
};
&io_expander10 {
gpio-line-names =
"FM_P12V_NIC1_FLTB_R_N","FM_P3V3_NIC1_FAULT_R_N",
- "OCP_V3_2_PWRBRK_FROM_HOST_ISO_PLD_N",
- "P12V_AUX_NIC1_SENSE_ALERT_R_N",
"FM_P12V_NIC0_FLTB_R_N","FM_P3V3_NIC0_FAULT_R_N",
- "OCP_SFF_PWRBRK_FROM_HOST_ISO_PLD_N",
- "P12V_AUX_NIC0_SENSE_ALERT_R_N",
+ "P48V_HS2_FAULT_N_PLD","P48V_HS1_FAULT_N_PLD",
+ "P12V_AUX_FAN_OC_PLD_N","P12V_AUX_FAN_FAULT_PLD_N",
+ "","",
+ "","",
+ "","FM_SYS_THROTTLE_N",
+ "OCP_V3_2_PWRBRK_FROM_HOST_ISO_PLD_N",
+ "OCP_SFF_PWRBRK_FROM_HOST_ISO_PLD_N";
+};
+
+&io_expander11 {
+ gpio-line-names =
"P12V_AUX_PSU_SMB_ALERT_R_L","P12V_SCM_SENSE_ALERT_R_N",
+ "P12V_AUX_NIC1_SENSE_ALERT_R_N","P12V_AUX_NIC0_SENSE_ALERT_R_N",
"NODEB_PSU_SMB_ALERT_R_L","NODEA_PSU_SMB_ALERT_R_L",
- "P52V_SENSE_ALERT_PLD_N","P48V_HS2_FAULT_N_PLD",
- "P48V_HS1_FAULT_N_PLD","";
+ "P12V_AUX_FAN_ALERT_PLD_N","P52V_SENSE_ALERT_PLD_N",
+ "PRSNT_RJ45_FIO_N_R","FM_MAIN_PWREN_RMC_EN_ISO_R",
+ "CHASSIS3_LEAK_Q_N_PLD","CHASSIS2_LEAK_Q_N_PLD",
+ "CHASSIS1_LEAK_Q_N_PLD","CHASSIS0_LEAK_Q_N_PLD",
+ "","SMB_RJ45_FIO_TMP_ALERT";
};
-&io_expander11 {
+&io_expander12 {
gpio-line-names =
"FAN_7_PRESENT_N","FAN_6_PRESENT_N",
"FAN_5_PRESENT_N","FAN_4_PRESENT_N",
"FAN_3_PRESENT_N","FAN_2_PRESENT_N",
"FAN_1_PRESENT_N","FAN_0_PRESENT_N",
- "PRSNT_CHASSIS3_LEAK_CABLE_R_N","PRSNT_CHASSIS1_LEAK_CABLE_R_N",
- "PRSNT_CHASSIS2_LEAK_CABLE_R_N","PRSNT_CHASSIS0_LEAK_CABLE_R_N",
- "PRSNT_RJ45_FIO_N_R","PRSNT_HDDBD_POWER_CABLE_N",
- "PRSNT_OSFP_POWER_CABLE_N","";
-};
-
-&io_expander12 {
- gpio-line-names =
- "RST_OCP_V3_1_R_N","NIC0_PERST_N",
- "OCP_SFF_PERST_FROM_HOST_ISO_PLD_N","OCP_SFF_MAIN_PWR_EN",
- "FM_OCP_SFF_PWR_GOOD_PLD","OCP_SFF_AUX_PWR_PLD_EN_R",
- "HP_LVC3_OCP_V3_1_PWRGD_PLD","HP_OCP_V3_1_HSC_PWRGD_PLD_R",
- "RST_OCP_V3_2_R_N","NIC1_PERST_N",
- "OCP_V3_2_PERST_FROM_HOST_ISO_PLD_N","OCP_V3_2_MAIN_PWR_EN",
- "FM_OCP_V3_2_PWR_GOOD_PLD","OCP_V3_2_AUX_PWR_PLD_EN_R",
- "HP_LVC3_OCP_V3_2_PWRGD_PLD","HP_OCP_V3_2_HSC_PWRGD_PLD_R";
-};
-
-&io_expander13 {
- gpio-line-names =
- "NODEA_NODEB_PWOK_PLD_ISO_R","PWR_EN_NICS",
- "PWRGD_P12V_AUX_FAN_PLD","P12V_AUX_FAN_EN_PLD",
- "PWRGD_P3V3_AUX_PLD","PWRGD_P12V_AUX_PLD_ISO_R",
- "FM_MAIN_PWREN_FROM_RMC_R","FM_MAIN_PWREN_RMC_EN_ISO_R",
- "PWRGD_RMC_R","PWRGD_P12V_AUX_FAN_PLD",
- "P12V_AUX_FAN_EN_PLD","FM_SYS_THROTTLE_N",
"HP_LVC3_OCP_V3_2_PRSNT2_PLD_N","HP_LVC3_OCP_V3_1_PRSNT2_PLD_N",
- "","";
+ "PRSNT_HDDBD_POWER_CABLE_N","PRSNT_OSFP0_POWER_CABLE_N",
+ "PRSNT_CHASSIS3_LEAK_CABLE_R_N","PRSNT_CHASSIS2_LEAK_CABLE_R_N",
+ "PRSNT_CHASSIS1_LEAK_CABLE_R_N","PRSNT_CHASSIS0_LEAK_CABLE_R_N";
};
-&io_expander14 {
- gpio-line-names =
- "","","","","","","","",
- "FM_BOARD_BMC_SKU_ID3","FM_BOARD_BMC_SKU_ID2",
- "FM_BOARD_BMC_SKU_ID1","FM_BOARD_BMC_SKU_ID0",
- "FAB_BMC_REV_ID2","FAB_BMC_REV_ID1",
- "FAB_BMC_REV_ID0","";
-};
--
2.31.1On Wed, 2024-11-06 at 16:58 +0800, Potin Lai wrote: > Update the GPIO linename of each PDB CPLD IO expander based on latest > CPLD firmware. What version is the latest CPLD firmware? What was the previous version with the old pin assignments? I'm also interested in some discussion of the coordination between CPLD firmware, the devicetree and the BMC userspace configuration. This change feels pretty painful. Andrew
On Thu, Nov 7, 2024 at 7:41 AM Andrew Jeffery <andrew@codeconstruct.com.au> wrote: > > On Wed, 2024-11-06 at 16:58 +0800, Potin Lai wrote: > > Update the GPIO linename of each PDB CPLD IO expander based on latest > > CPLD firmware. > > What version is the latest CPLD firmware? What was the previous version > with the old pin assignments? Because the hardware changes from EVT to DVT, the CPLD firmware reallocated the IOEXP pin mapping in DVT version. I will add more description into the commit message in the next version. > > I'm also interested in some discussion of the coordination between CPLD > firmware, the devicetree and the BMC userspace configuration. This > change feels pretty painful. I am not from the CPLD firmware team, I only know our CPLD team was redesigning the entire struct which causes the huge changes of IOEXP pins. This is probably a different topic, I am curious about is it possible to assign the linename in userspace? In OpenBMC, there are many services that depend on GPIO linename, it will be more flexible if I can assign the linename before service starts. Thanks, Potin > > Andrew
On Thu, 2024-11-07 at 19:22 +0800, Potin Lai wrote: > On Thu, Nov 7, 2024 at 7:41 AM Andrew Jeffery > <andrew@codeconstruct.com.au> wrote: > > > > On Wed, 2024-11-06 at 16:58 +0800, Potin Lai wrote: > > > Update the GPIO linename of each PDB CPLD IO expander based on > > > latest > > > CPLD firmware. > > > > What version is the latest CPLD firmware? What was the previous > > version > > with the old pin assignments? > > Because the hardware changes from EVT to DVT, the CPLD firmware > reallocated the IOEXP pin mapping in DVT version. > I will add more description into the commit message in the next > version. If you have different revisions of the board, it would seem sensible to have separate devicetrees, one for each, rather than constantly evolving one devicetree? Tack on an `-evt`/`-dvt` suffix as required? From there you can always have a suffix-less dts file that #includes the most recent board revision. See some of the Aspeed EVB devicetrees for an example. > > > > > I'm also interested in some discussion of the coordination between > > CPLD > > firmware, the devicetree and the BMC userspace configuration. This > > change feels pretty painful. > > I am not from the CPLD firmware team, I don't see why you need to be? This is a cross-component concern, and you need to make all the pieces of the puzzle line up. > I only know our CPLD team was > redesigning the entire struct which causes the huge changes of IOEXP > pins. > > This is probably a different topic, I am curious about is it possible > to assign the linename in userspace? > In OpenBMC, there are many services that depend on GPIO linename, it > will be more flexible if I can assign the linename before service > starts. Not that I'm aware, and to determine otherwise I'd probably need to read the implementation as much as you :) However, separating the devicetrees would go a long way here if the CPLD firmware is tied to the board revision... Andrew
© 2016 - 2024 Red Hat, Inc.