Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / phosphor-power / 592bd27cce59ac57031b0e439371bee166a6ee7b
commit592bd27cce59ac57031b0e439371bee166a6ee7b[log] [tgz]
authorMatt Spinler <spinler@us.ibm.com>Wed Aug 30 11:00:01 2023 -0500
committerMatt Spinler <spinler@us.ibm.com>Thu Sep 07 12:50:35 2023 -0500
tree6f8a0f1dba1b20fa7addcafd4def19800127097f
parentd6760265e74938f6acf49d3be9b9aecee42ae2b4 [diff]
psu-ng: Add peak input power sensor for some PSs

Some models of the ibm-cffps power supplies support an 'input history'
command that reports 30 second maximum and average input power values.
The code was currently putting those on an 'org.open_power' D-Bus
interface so that the history of those values could be captured in a
single D-Bus call.

Now that there is a real telemetry feature in Redfish that can capture
the history of a single sensor value, we can drop the custom D-Bus
interface and just use the normal Sensor.Value interface that contains
the most recent maximum value from the input history command, The sensor
name will be 'psX_input_power_peak' where X is the PS instance number.

The average input power telemetry will now just be obtained from the
psX_input_power sensor provided by phosphor-hwmon so an equivalent
sensor to the peak isn't needed here.

This commit will add support for putting the new sensor on D-Bus, and a
future one will remove the previous input history support.

Like sensors in other daemons, it will be set to not available when a PS
is removed, and not functional when it has an access problem.  There
will be associations to the parent chassis and to the power supply so it
will show up in Redfish output with the other sensors.

This commit did remove one of the input history testcases, as trying to
get the right sequence of EXPECT_CALLs would get tricky when both the
old and new are running together.

Tested:
- New sensor shows up when PS is present and supports it.
 - All interfaces on the object path are correct.
- Sensor value matches what org.open_power Max property had.
- Works correctly when:
 - PS is missing on startup
 - PS is removed
 - Previously present PS is replaced.

Change-Id: Id9c33aa753c9af32880a0cc874b39c113222568f
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
6 files changed
tree: 6f8a0f1dba1b20fa7addcafd4def19800127097f
  1. cold-redundancy/
  2. example/
  3. org/
  4. phosphor-power-sequencer/
  5. phosphor-power-supply/
  6. phosphor-regulators/
  7. power-sequencer/
  8. power-supply/
  9. services/
  10. subprojects/
  11. test/
  12. tools/
  13. .clang-format
  14. .gitignore
  15. .shellcheck
  16. device.hpp
  17. device_monitor.hpp
  18. elog-errors.hpp
  19. file_descriptor.hpp
  20. gpio.cpp
  21. gpio.hpp
  22. LICENSE
  23. meson.build
  24. meson.options
  25. names_values.hpp
  26. OWNERS
  27. pmbus.cpp
  28. pmbus.hpp
  29. README.md
  30. types.hpp
  31. utility.cpp
  32. utility.hpp
README.md

Overview

This repository contains applications for configuring and monitoring devices that deliver power to the system.

  • cold-redundancy: Application that makes power supplies work in Cold Redundancy mode and rotates them at intervals.
  • phosphor-power-sequencer: Applications for configuring and monitoring power sequencer and related devices that support JSON-driven configuration.
  • phosphor-power-supply: Next generation power supply monitoring application.
  • phosphor-regulators: JSON-driven application that configures and monitors voltage regulators.
  • power-sequencer: A power sequencer monitoring application.
  • power-supply: Original power supply monitoring application.
  • tools/power-utils: Power supply utilities.

Build

To build all applications in this repository:

  meson build
  ninja -C build

To clean the repository and remove all build output:

  rm -rf build

You can specify meson options to customize the build process. For example, you can specify:

  • Which applications to build and install.
  • Application-specific configuration data, such as power sequencer type.
  • Whether to build tests.

Power Supply Monitor and Util JSON config

Several applications in this repository require a PSU JSON config to run. The JSON config file provides information for:

  • Where to access the pmbus attributes
  • Which attribute file in pmbus maps to which property and interface in D-Bus
  • Which kernel device directory is used on which PSU

There is an example psu.json to describe the necessary configurations.

  • inventoryPMBusAccessType defines the pmbus access type, which tells the service which sysfs type to use to read the attributes. The possible values are:
    • Base: The base dir, e.g. /sys/bus/i2c/devices/3-0069/
    • Hwmon: The hwmon dir, e.g. /sys/bus/i2c/devices/3-0069/hwmon/hwmonX/
    • Debug: The pmbus debug dir, e.g. /sys/kernel/debug/pmbus/hwmonX/
    • DeviceDebug: The device debug dir, e.g. '/sys/kernel/debug/./`
    • HwmonDeviceDebug: The hwmon device debug dir, e.g. /sys/kernel/debug/pmbus/hwmonX/cffps1/
  • fruConfigs defines the mapping between the attribute file and the FRU inventory interface and property. The configuration example below indicates that the service will read part_number attribute file from a directory specified by the above pmbus access type, and assign to PartNumber property in xyz.openbmc_project.Inventory.Decorator.Asset interface.
      "fruConfigs": [
    {
      "propertyName": "PartNumber",
      "fileName": "part_number",
      "interface": "xyz.openbmc_project.Inventory.Decorator.Asset"
    }
  ]
  • psuDevices defines the kernel device dir for each PSU in inventory. The configuration example below indicates that powersupply0's device is located in /sys/bus/i2c/devices/3-0069.
      "psuDevices": {
    "/xyz/openbmc_project/inventory/system/chassis/motherboard/powersupply0" : "/sys/bus/i2c/devices/3-0069",
  }