summaryrefslogtreecommitdiffstats
path: root/monitor/gen-fan-monitor-defs.py
Commit message (Collapse)AuthorAgeFilesLines
* Add target interface for fan monitorLei YU2018-02-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Current fan monitor assumes the use of the FanSpeed interface for fan targets. For fans controlled by pwm, FanPwm interface is added. This commit adds a "target_interface" config parameter, so that user can specify the interface for the fan targets. E.g. - name: fan0 has_target: true target_interface: xyz.openbmc_project.Control.FanPwm This config is optional and defaults to FanSpeed, so the current code will not be affected. Tested: Use this config on Romulus, ensures fan monitor gets fan target from FanPwm interface and works OK. Change-Id: I262a486c335b2b43a46af7abdd0e71e95a133b98 Signed-off-by: Lei YU <mine260309@gmail.com>
* Add factor and offset for fan monitorLei YU2018-02-261-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For fans controlled via pwm, the fan target and speed are different, where the fan target is pwm and the speed is rpm. Usually it is a linear mapping from pwm to rpm. So this commit defines the optional configs, factor and offset for calculating the expected fan speed from target, e.g. - name: fan0 has_target: true factor: 21 offset: 1600 The fan monitor service will calculate expected fan speed as: target * factor + offset The default value is 1 for factor and 0 for offset if they are not defined. Tested: Use this config together with the following commit's changes, test on Romulus and ensures the fan monitor works OK; Without this config, fan monitor always mark fans as non-functional due to the fan speed does not match the pwm value. Change-Id: If5e25368b4530df7a7face9377efb58804db21df Signed-off-by: Lei YU <mine260309@gmail.com>
* monitor: Update YAML parser to handle trust groupsMatt Spinler2017-10-111-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | It creates a list of group creator lambdas based on the information in the monitor YAML file. These lambdas are called by the manager class to create the trust group instances. A real life example is: const std::vector<CreateGroupFunction> trustGroups { { []() { std::vector<std::string> names{ "fan0_1", "fan1_1", "fan2_1", "fan3_1", }; return std::make_unique<NonzeroSpeed>(names); } }, }; Change-Id: Ia883df35efb86242aae2f8ed7d1714e94e65a6e6 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Python script to generate monitor dataMatt Spinler2017-05-111-0/+73
Generate the data structures from yaml data. Change-Id: I8e21fa099f9365b8c8c7d2227c4debc263601b72 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
OpenPOWER on IntegriCloud