Support multiple power caps on a system based on the power supply (type and number present) and input voltage.
For initial GA, the n and n+1 bulk power limits were hardcoded in MRW HB attributes and read by HTMGT/OCC, independent of the type of ps attached.
This is required for the following systems:
1) 1S4U when supported with 2x 1000W supplies
2) 2S2U when supported with 2x 1000W supplies *this one specifically may require looking at combination of power supply and input voltage, not just supply
01/18/22 update
There are no BMC GUI or redfish impacts.
BMC power management needs to know ps type and the number of ps that are possible i.e. 1+1 or 2+2. This info will be used to setup oversubscription therefore the 1+1 config will not show oversubscription until it actually drops to 1 power supply which would be a valid oversubscription error. Unlike in P9 where we shipped "in oversubscription" with 2 power supplies and the def file told us not to log the oversub error, we do not need the ignore oversub support here since the 1+1 will not be in oversubscription until it actually drops to 1 supply. This is also a more correct implementation than P9 by allowing the capability to have a real 1 ps oversubscription limit instead of using the same oversub limit as the 2+2.
To know the number of ps manufacturing will need to write a keyword in the backplane VPD.
NOTE: Manufacturing must already know if the system is shipping as 1+1 or 2+2.
HTMGT will query BMC for the power supply information type and number. HTMGT will then use this information to look up in the xml the power limits to be passed to the OCC. Changing ps type config at runtime is not supported in the field and we are not going to support runtime power supply events to change power limits based on ps config. However, it could take "a while" for the EM config to show up, or the PS may not have AC so the input value will be unknown - make sure these are handled.
rfrandse
commented
1 year ago
Support multiple power caps on a system based on the power supply (type and number present) and input voltage. For initial GA, the n and n+1 bulk power limits were hardcoded in MRW HB attributes and read by HTMGT/OCC, independent of the type of ps attached.
This is required for the following systems: 1) 1S4U when supported with 2x 1000W supplies 2) 2S2U when supported with 2x 1000W supplies *this one specifically may require looking at combination of power supply and input voltage, not just supply
01/18/22 update There are no BMC GUI or redfish impacts. BMC power management needs to know ps type and the number of ps that are possible i.e. 1+1 or 2+2. This info will be used to setup oversubscription therefore the 1+1 config will not show oversubscription until it actually drops to 1 power supply which would be a valid oversubscription error. Unlike in P9 where we shipped "in oversubscription" with 2 power supplies and the def file told us not to log the oversub error, we do not need the ignore oversub support here since the 1+1 will not be in oversubscription until it actually drops to 1 supply. This is also a more correct implementation than P9 by allowing the capability to have a real 1 ps oversubscription limit instead of using the same oversub limit as the 2+2.
To know the number of ps manufacturing will need to write a keyword in the backplane VPD.
NOTE: Manufacturing must already know if the system is shipping as 1+1 or 2+2.
HTMGT will query BMC for the power supply information type and number. HTMGT will then use this information to look up in the xml the power limits to be passed to the OCC. Changing ps type config at runtime is not supported in the field and we are not going to support runtime power supply events to change power limits based on ps config. However, it could take "a while" for the EM config to show up, or the PS may not have AC so the input value will be unknown - make sure these are handled.