commit | 1a309f77e3610276de43befafa295b35f619f005 | [log] [tgz] |
---|---|---|
author | Matt Spinler <spinler@us.ibm.com> | Tue Apr 04 13:12:19 2023 -0500 |
committer | Matt Spinler <spinler@us.ibm.com> | Thu Jun 29 15:31:49 2023 +0000 |
tree | 02bfc968160eea3de19e36712fceb40a69991d04 | |
parent | 9479b06c67fe7bd69bbbcc3e3e39cd51e4814c9f [diff] |
Create a custom power button handler IBM has specific requirements on how the power button must behave, which are different than what the button handler currently does. These requirements are: If power is off: - A button press will power on as long as the BMC is in the ready state. If power is on: - A button press less than 4s won't do anything. - At 4s, issue a host power off and start a 10s timer. - If the button is released within that 10s and not pressed again, continue with the host power off. - If the button is released within that 10s and also pressed again in that 10s, do a hard power (chassis) off. - If the button is pressed throughout that 10s issue a hard power off. Instead of trying to integrate this behavior into the main button handler code using even more #ifdefs in various spots, this commit creates the concept of custom power button handlers, and then implements one. This makes it less likely it could subtly break when changes are made to the default code. A 'power-button-handler' meson option is used to select the handler, where the default uses the current behavior. A PowerButtonHandlerFactory then creates the appropriate instance of the handler selected by that option. If a handler is found, then the default matches/callbacks won't be done and the handler can deal with them as it sees fit. Handlers are derived from a PowerButtonHandler abstract base class that has 2 pure virtual functions: - void pressed(); - void released(uint64_t pressTimeMS); It will register for the power button pressed/released signals and then call these overridden functions appropriately. This new handler is implemented in a HostThenChassisPowerOff class. Change-Id: I3a1df688c4393b4643d42e91c075379f9a266eef Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Phosphor-buttons has a collection of IO event handler interfaces for physical inputs which are part of OCP front panel.
It defines an individual dbus interface object for each physical button/switch inputs such as power button, reset button etc. Each of this button interfaces monitors it's associated io for event changes and calls the respective event handlers.
In order to monitor a button/input interface the respective gpio config details should be mentioned in the gpio defs json file - /etc/default/obmc/gpio/gpio_defs.json
{ "gpio_definitions": [ { "name": "POWER_BUTTON", "gpio_config" :[ { "pin": "D0", "direction": "both" } ] }, { "name": "RESET_BUTTON", "gpio_config" :[ { "pin": "AB0", "direction": "both" } ] }, { "name" : "HOST_SELECTOR", "group_gpio_config" : [ { "pin": "AA4", "direction": "both" }, { "pin": "AA5", "direction": "both" }, { "pin": "AA6", "direction": "both" }, { "pin": "AA7", "direction": "both" } ] }, }
This config is original config which can be used for configs with only single gpio such as power button,reset button, OCP debug card host select button.
{ "name": "POWER_BUTTON", "pin": "D0", "direction": "both" },
Note: this config is used by most of the other platforms so this format is kept as it is so that existing gpio configs do not get affected.
The following configs are related to multi-host bmc systems more info explained in the design: https://github.com/openbmc/docs/blob/master/designs/multihost-phosphor-buttons.md
The host selector has four gpios associated. So the related gpios are mentioned in a json array named group_gpio_config.
Example : The value of "7" derived from the 4 host select gpio lines are mapped to host position 1.
{ "name": "HOST_SELECTOR", "group_gpio_config": [ { "name": "host_select_0", "pin": "AA4", "direction": "both", "polarity": "active_high" }, { "name": "host_select_1", "pin": "AA5", "direction": "both", "polarity": "active_high" }, { "name": "host_select_2", "pin": "AA6", "direction": "both", "polarity": "active_high" }, { "name": "host_select_3", "pin": "AA7", "direction": "both", "polarity": "active_high" } ], "max_position": 4, "host_selector_map": { "6": 0, "7": 1, "8": 2, "9": 3, "10": 4, "11": 0, "12": 1, "13": 2, "14": 3, "15": 4 } }
There are also some systems that get the host selector selection from the CPLD, the configuration is provided below.
{ "cpld_definitions": [ { "name": "HOST_SELECTOR", "i2c_bus": 12, "i2c_address": 15, "register_name": "uart-selection-debug-card", "max_position": 4 } ] }
Similar to host selector there are multiple gpios associated with the serial uart mux. These gpio configs are specificed as part of json array "group_gpio_config".
Here the serial uart mux output is accessed via OCP debug card. SO the OCP debug card present gpio is mentioned part of the group_gpio_config. The debug card present gpio is identified by its name "debug_card_present".
The other gpios part of the group gpio config is serial uart MUX gpio select lines and serial_uart_rx line.
{ "name": "SERIAL_UART_MUX", "group_gpio_config": [ { "name": "serial_uart_sel_0", "pin": "E0", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_1", "pin": "E1", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_2", "pin": "E2", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_sel_3", "pin": "E3", "direction": "out", "polarity": "active_high" }, { "name": "serial_uart_rx", "pin": "E4", "direction": "out", "polarity": "active_high" }, { "name": "debug_card_present", "pin": "R3", "direction": "both", "polarity": "active_high" } ], "serial_uart_mux_map": { "0": 4, "1": 0, "2": 1, "3": 2, "4": 3 } }