| commit | f7b0e07121a5ff287c7d8ffac411b732e592ae05 | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <edtanous@google.com> | Thu Nov 05 08:34:43 2020 -0800 |
| committer | Patrick Williams <patrick@stwcx.xyz> | Wed Dec 02 16:59:36 2020 +0000 |
| tree | aed18a468169186b3398d87d7e87e6a4d67ef840 | |
| parent | a1e0916223000127a575e6d7154fc2f9117c4f1c [diff] |
Add Voltage Regulator Control interfaces There are many cases where a BMC might need to control a Voltage Regulator. This commit adds 2 new interfaces for said control intended to allow implementing this functionality. VoltageRegulatorControl interface is intended to represent the "lowest" level of a voltage regulator control interface, and allows setting a voltage target for a given VR in Volts. This is intended to be used by platform specific logic internal to the BMC, that might have access to chip/implementation specific manufacturing calibrations, and has the ability to call out an exact voltage. Setting the value property of said interface is expected to do the VR specific actions, likely an smbus/pmbus change operation, to set said voltage on the device. Clients might also register for changes to the voltage, and make other functional changes, such as an ADC sensor changing target and thresholds based on the VR target. VoltageRegulatorProfile interface is to provide a platform specific "high level" interface, intended to satisfy users outside the BMC that need the ability to set various "modes" a VR can obey. It is intentionally implemented as a platform specific interface, as there is no such thing as a platform agnostic "voltage profile" and available options and mode can vary significantly from system to system, chip to chip, and vr to vr. The likelihood that we could cover a superset of cases seems unlikely, so it was intentionally discounted in this commit as an option. The concept for this is very similar to the Control.ThermalMode interface, which also implements very platform-specific behavior for thermal modes, which has nearly identical constraints, hence it was a good model to follow for this interface. Mailing list discussion on topic: https://lore.kernel.org/openbmc/CAH2-KxCDtq4TDhcENWB65neeqq2QW2TDTV4e7mudaram5EcWGg@mail.gmail.com/ Signed-off-by: Ed Tanous <edtanous@google.com> Change-Id: I41445f8c273456ce505c02ef135c8c81a5ca6ece
YAML descriptors of standard D-Bus interfaces. The format is described by the sdbusplus binding generation tool sdbus++.
This project can be built with meson. The typical meson workflow is: meson builddir && ninja -C builddir.
The meson files used to handle the YAML files are automatically generated and found under the gen subdirectory. When adding or removing YAML files, this must be regenerated. This can be done with the helper script found in the gen subdirectory: cd gen && ./regenerate-meson.
Only the xyz/openbmc_project interfaces are built by default. Other interfaces can be enabled by meson options:
-Ddata_com_ibm=true-Ddata_org_open_power=trueExample: meson builddir -Ddata_com_ibm=true && ninja -C builddir