| /openbmc/openbmc-test-automation/redfish/extended/ |
| H A D | test_power_capping.robot | 2 Documentation Energy scale power capping tests.
6 # PL Power Limit
35 [Documentation] Change active power limit with system power on and
36 ... Power limit active.
39 Set DCMI Power Limit And Verify ${max_power}
41 Redfish Power On stack_mode=skip
67 ${power}= Get DCMI Power Limit
68 Should Be True ${power} == ${max_power}
69 ... msg=DCMI power limit should be ${max_power}.
71 Activate DCMI Power And Verify
[all …]
|
| H A D | test_escale_base.robot | 29 # The power limits are documented in
30 # open-power/witherspoon-xml/master/witherspoon.xml.
37 [Documentation] Run base power tests with DCMI power monitoring off.
40 Deactivate DCMI Power And Verify
41 Verify Power Limits
45 [Documentation] Run base power tests with DCMI power monitoring on.
48 Activate DCMI Power And Verify
49 Verify Power Limits
52 Escale Power Setting Via REST And Verify
53 [Documentation] Set power via REST and check using IPMI.
[all …]
|
| /openbmc/openbmc/meta-ibm/recipes-phosphor/dbus/power-supply-policy/ |
| H A D | power-supply-policy.yaml | 1 # Machine power supply policy for PDM.
3 # Create an error if a power supply is removed while the system is powered on
5 - name: power supply0
9 - meta: POWER SUPPLY
12 - name: power supply1
16 - meta: POWER SUPPLY
19 - name: power supplies
21 'The machine has two power supplies to monitor.'
25 - meta: POWER SUPPLY
27 - meta: POWER SUPPLY
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/csdl/ |
| H A D | Power_v1.xml | 4 <!--# Redfish Schema: Power v1.7.3 -->
43 <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="Power">
47 <EntityType Name="Power" BaseType="Resource.v1_0_0.Resource" Abstract="true">
48 ….Description" String="The `Power` schema describes power metrics and represents the properties for…
49 …<Annotation Term="OData.LongDescription" String="This resource shall contain the power metrics for…
58 …tring="Any writable properties, such as limits and exceptions, can be updated for power metrics."/>
68 <String>/redfish/v1/Chassis/{ChassisId}/Power</String>
73 <String>/redfish/v1/Chassis/{ChassisId}/Power</String>
88 … <Annotation Term="OData.Description" String="This action resets the targeted power supply."/>
89 …power supply specified by the `MemberId` from the `PowerSupplies` array. A `GracefulRestart` `Res…
[all …]
|
| /openbmc/bmcweb/redfish-core/schema/dmtf/installed/ |
| H A D | Power_v1.xml | 4 <!--# Redfish Schema: Power v1.7.3 -->
43 <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="Power">
47 <EntityType Name="Power" BaseType="Resource.v1_0_0.Resource" Abstract="true">
48 ….Description" String="The `Power` schema describes power metrics and represents the properties for…
49 …<Annotation Term="OData.LongDescription" String="This resource shall contain the power metrics for…
58 …tring="Any writable properties, such as limits and exceptions, can be updated for power metrics."/>
68 <String>/redfish/v1/Chassis/{ChassisId}/Power</String>
73 <String>/redfish/v1/Chassis/{ChassisId}/Power</String>
88 … <Annotation Term="OData.Description" String="This action resets the targeted power supply."/>
89 …power supply specified by the `MemberId` from the `PowerSupplies` array. A `GracefulRestart` `Res…
[all …]
|
| /openbmc/docs/designs/ |
| H A D | psu-monitoring.md | 1 # Power Supply Monitoring Application
11 This is a proposal to provide a set of enhancements to the current OpenBMC power
13 may consist of a number of configuration variations including different power
15 different power supplies is needed in order to initialize the power supplies,
23 that contains a power supply monitor application and a power sequencer monitor
24 application. The current power supply application is lacking things desired for
28 a single power supply application that can communicate with one or more
29 [PMBus][2] power supplies and provide the enterprise features currently lacking
31 power supply.
38 1. The power supply application must detect, isolate, and report individual
[all …]
|
| H A D | power-recovery.md | 1 # OpenBMC Server Power Recovery
11 Modern computer systems have a feature, automated power-on recovery, which in
13 power to the system. If the system had a black out (i.e. power was completely
14 cut to the system), should it automatically power the system on? Should it leave
16 at before the power loss.
18 There are also instances where the user may not want automatic power recovery to
22 situations, the user may wish for the system to not automatically power on the
26 run once the power is restored. For example, IBM requires all LED's be toggled
30 A brownout is another scenario that commonly utilizes automated power-on
32 told) that chassis power can no longer be supported, but power to the BMC will
[all …]
|
| /openbmc/openbmc-test-automation/lib/ |
| H A D | energy_scale_utils.robot | 2 Documentation Utilities for power management tests.
16 Get System Power Cap Limit
17 [Documentation] Get the allowed MAX and MIN power limit of the chassis.
19 # GET request of /redfish/v1/Chassis/chassis/EnvironmentMetrics | grep -A5 Power
32 DCMI Power Get Limits
33 [Documentation] Run dcmi power get_limit and return values as a
36 # This keyword packages the five lines returned by dcmi power get_limit
38 # Current Limit State: No Active Power Limit
39 # Exception actions: Hard Power Off & Log Event to SEL
40 # Power Limit: 500 Watts
[all …]
|
| /openbmc/u-boot/include/ |
| H A D | power-domain.h | 10 * A power domain is a portion of an SoC or chip that is powered by a
11 * switchable source of power. In many cases, software has control over the
12 * power domain, and can turn the power source on or off. This is typically
13 * done to save power by powering off unused devices, or to enable software
15 * drivers to turn power domains on and off.
17 * A driver that implements UCLASS_POWER_DOMAIN is a power domain controller or
18 * provider. A controller will often implement multiple separate power domains,
20 * power-domain-uclass.h describes the interface which power domain controllers
23 * Depending on the power domain controller hardware, changing the state of a
24 * power domain may require performing related operations on other resources.
[all …]
|
| /openbmc/phosphor-power/phosphor-power-sequencer/docs/ |
| H A D | powering_on.md | 3 ## Initiating a power on
6 Redfish command, or a power button on the system enclosure.
9 `org.openbmc.control.Power` D-Bus interface. The D-Bus object path is
13 The `phosphor-power-sequencer` application only supports powering on the entire
14 system. In a multiple chassis system, `phosphor-power-sequencer` does not
17 ## Determining which chassis to power on
19 In a single chassis system, `phosphor-power-sequencer` will always attempt to
20 power on the chassis.
22 In a multiple chassis system, `phosphor-power-sequencer` will only attempt to
23 power on chassis with the proper status:
[all …]
|
| H A D | README.md | 1 # phosphor-power-sequencer
5 The `phosphor-power-sequencer` application powers all the chassis in the system
6 on and off. It also monitors the power good (pgood) state in each chassis.
12 `phosphor-chassis-power` application. This disclaimer will be removed when this
17 `phosphor-power-sequencer` is a single-threaded C++ executable. It is a daemon
21 `phosphor-power-sequencer` is driven by an optional, system-specific JSON
24 chassis, power sequencer devices, voltage rails, GPIOs, and fault checks to
29 ## Power sequencer device
31 A power sequencer device enables (turns on) the voltage rails in the correct
34 `phosphor-power-sequencer` currently supports the following power sequencer
[all …]
|
| H A D | monitoring_chassis_pgood.md | 1 # Monitoring Chassis Power Good
5 The power sequencer device provides a chassis power good (pgood) signal. This
8 The `phosphor-power-sequencer` application periodically reads (polls) the
16 If the chassis pgood state is false when it should be true, a chassis power good
17 (pgood) fault has occurred. See [Power Good Faults](pgood_faults.md) for more
20 ## Unable to read chassis power good signal
22 `phosphor-power-sequencer` may become unable to read the chassis power good
29 ### During power on
31 If `phosphor-power-sequencer` is unable to read the chassis power good signal
32 during a power on attempt, the application will do the following:
[all …]
|
| H A D | chassis_status.md | 6 status. The `phosphor-power-sequencer` application publishes one of those
8 used as input by `phosphor-power-sequencer.`
12 The `state` and `pgood` properties exist on the `org.openbmc.control.Power`
15 `state` has a value of 0 or 1. `state` represents the desired power state for
19 `pgood` has a value of 0 or 1. `pgood` represents the power good (pgood) state
20 of the chassis. 0 means off, and 1 means on. This is the actual, current power
21 state. This property is set based on the chassis power good signal from the
22 power sequencer device.
24 `phosphor-power-sequencer` publishes the `org.openbmc.control.Power` interface
61 power on some chassis, such as if they are missing or have no input power. See
[all …]
|
| H A D | powering_off.md | 3 ## Initiating a power off
6 Redfish command, or a power button on the system enclosure.
9 `org.openbmc.control.Power` D-Bus interface. The D-Bus object path is
13 The `phosphor-power-sequencer` application only supports powering off the entire
14 system. In a multiple chassis system, `phosphor-power-sequencer` does not
17 ## Determining which chassis to power off
19 In a single chassis system, `phosphor-power-sequencer` will always attempt to
20 power off the chassis.
22 In a multiple chassis system, `phosphor-power-sequencer` will only attempt to
23 power off chassis with the proper status:
[all …]
|
| H A D | power_loss.md | 1 # Power Loss
5 Power distribution in a computer system is complex. It typically flows from a
6 wall outlet to power supplies to voltage regulators to system components. Other
7 devices may exist between the wall outlet and the power supplies, such as an
8 Uninterruptible Power Supply (UPS) or an Enclosure Power Distribution Unit
11 A **brownout** is a partial reduction in voltage to the power supplies. In some
14 processor and other system components have lost power.
16 A **blackout** is a complete loss of power to the power supplies.
24 `phosphor-power-sequencer` application will take no action.
26 If the chassis was powered on when the brownout occurred, the power sequencer
[all …]
|
| H A D | pgood_faults.md | 1 # Power Good Faults
5 The power sequencer device provides a chassis power good (pgood) signal. This
8 If the chassis pgood state is false when it should be true, a chassis power good
13 When the power sequencer device is powering on the main voltage rails in order,
14 one of the rails may fail to power on. This is often due to a hardware problem.
16 When a voltage rail fails to power on, the power sequencer device may
18 for the rail to power on. In both cases the chassis pgood signal never changes
26 A voltage rail may suddenly power off or stop providing the expected level of
30 The power sequencer device will detect that the voltage rail has failed. The
32 may also power off several other related voltage rails, depending on how the
[all …]
|
| /openbmc/u-boot/arch/powerpc/dts/ |
| H A D | e6500_power_isa.dtsi | 3 * e6500 Power ISA Device Tree Source (include)
11 power-isa-version = "2.06";
12 power-isa-b; // Base
13 power-isa-e; // Embedded
14 power-isa-atb; // Alternate Time Base
15 power-isa-cs; // Cache Specification
16 power-isa-ds; // Decorated Storage
17 power-isa-e.ed; // Embedded.Enhanced Debug
18 power-isa-e.pd; // Embedded.External PID
19 power-isa-e.hv; // Embedded.Hypervisor
[all …]
|
| /openbmc/u-boot/drivers/power/domain/ |
| H A D | Kconfig | 1 menu "Power Domain Support"
4 bool "Enable power domain support using Driver Model"
7 Enable support for the power domain driver class. Many SoCs allow
8 power to be applied to or removed from portions of the SoC (power
9 domains). This may be used to save power. This API provides the
10 means to control such power management hardware.
13 bool "Enable the BCM6328 power domain driver"
16 Enable support for manipulating BCM6345 power domains via MMIO
20 bool "Enable i.MX8 power domain driver"
23 Enable support for manipulating NXP i.MX8 on-SoC power domains via IPC
[all …]
|
| /openbmc/openbmc-test-automation/data/boot_lists/ |
| H A D | All | 1 REST Power On
2 REST Power On (mfg)
3 Redfish Power On
4 Redfish Power On (mfg)
5 IPMI Power On
6 IPMI Power On (mfg)
7 Istep Power On
8 Istep Power On (mfg)
9 REST Power Off
10 REST Power Off (mfg)
[all …]
|
| H A D | Power_off | 1 REST Power Off
2 REST Power Off (mfg)
3 Redfish Power Off
4 Redfish Power Off (mfg)
5 REST Hard Power Off
6 REST Hard Power Off (mfg)
7 Redfish Hard Power Off
8 Redfish Hard Power Off (mfg)
9 IPMI Power Off
10 IPMI Power Off (mfg)
[all …]
|
| /openbmc/docs/designs/oem/ibm/ |
| H A D | system-power-mode.md | 1 # System Power Mode and Idle Power Saver Support
11 Power management on POWER platforms needs assistance from the BMC for managing
12 the system power mode and idle power save modes. We need the ability to set and
13 query the system power mode and also the ability to control and set idle power
14 save parameters. This design is only applicable to POWER processors.
18 Each POWER processor contains an embedded PowerPC 405 processor that is referred
19 to as the On Chip Controller or OCC. The OCC provides real time power and
22 send a mode change and idle power saver (IPS) settings to the OCC. It will also
23 need to send the commands if the user changes the mode or idle power save
29 state, the OCC is managing the processor frequency, power consumption, and
[all …]
|
| /openbmc/u-boot/arch/arm/mach-exynos/ |
| H A D | power.c | 9 #include <asm/arch/power.h>
41 struct exynos5_power *power = in exynos5_set_usbhost_phy_ctrl() local
46 setbits_le32(&power->usbhost_phy_control, in exynos5_set_usbhost_phy_ctrl()
50 clrbits_le32(&power->usbhost_phy_control, in exynos5_set_usbhost_phy_ctrl()
57 struct exynos4412_power *power = in exynos4412_set_usbhost_phy_ctrl() local
62 setbits_le32(&power->usbhost_phy_control, in exynos4412_set_usbhost_phy_ctrl()
64 setbits_le32(&power->hsic1_phy_control, in exynos4412_set_usbhost_phy_ctrl()
66 setbits_le32(&power->hsic2_phy_control, in exynos4412_set_usbhost_phy_ctrl()
70 clrbits_le32(&power->usbhost_phy_control, in exynos4412_set_usbhost_phy_ctrl()
72 clrbits_le32(&power->hsic1_phy_control, in exynos4412_set_usbhost_phy_ctrl()
[all …]
|
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/State/ |
| H A D | Chassis.interface.yaml | 1 description: Implement to provide the chassis power management
8 The desired power transition to start on this chassis. This will be
9 preserved across AC power cycles of the BMC.
17 A read-only property describing the current chassis power state. A
24 A read-only property describing the current chassis power status. This
26 power coming into the chassis. Note that this is different then the
27 CurrentPowerState in that it provides status of the power coming into
28 the chassis, not the actual state of the chassis power.
33 The last time at which the chassis power changed state, as tracked by
40 The desired power transition for the chassis
[all …]
|
| /openbmc/witherspoon-pfault-analysis/org/open_power/Witherspoon/ |
| H A D | Fault.errors.yaml | 3 The power supply has indicated an input or under voltage condition. Check
4 the power supply cabling and/or input power source.
7 description: The power supply indicated that it is not on when it should be.
10 description: The power supply detected an output overcurrent fault condition.
13 description: The power supply detected an output overvoltage fault condition.
16 description: The power supply detected bad fan operation.
19 description: The power supply has had an over temperature condition.
22 description: A power off was issued because a power fault was detected
25 description: System power failed to turn on
28 description: The power sequencer chip detected a voltage fault
[all …]
|
| /openbmc/openpower-occ-control/ |
| H A D | powercap.hpp | 9 #include <xyz/openbmc_project/Control/Power/CapLimits/server.hpp>
29 namespace Base = sdbusplus::xyz::openbmc_project::Control::Power::server;
56 /** @brief Loads any saved power cap data */
62 /** @brief Save Power Mode data to persistent file
64 * @param[in] softMin - soft minimum power cap in Watts
65 * @param[in] hardMin - hard minimum power cap in Watts
66 * @param[in] max - maximum power cap in Watts
78 /** @brief Return the power cap limits
80 * @param[out] softMin - soft minimum power cap in Watts
81 * @param[out] hardMin - hard minimum power cap in Watts
[all …]
|