| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the functional infrastructure to optionally attach a condition
function to a fan definition. When a condition is defined on a fan, it
must be true for a fan's associated functional properties to be created.
When the given condition fails, that fan's functional properties will
not be created by fan monitor. A fan without a defined condition will
have all of its associated functional properties created.
Example of generated condition (generation commit to follow):
make_condition(condition::propertiesMatch(
std::vector<PropertyState>{
PropertyState{
PropertyIdentity{
"/xyz/openbmc_project/inventory/system/chassis",
"xyz.openbmc_project.Inventory.Decorator.CoolingType",
"WaterCooled"
},
static_cast<bool>(false)
}
}
)),
Tested:
Fan functional properties are not created when a condition fails
Fan functional properties are created when condition passes
Fan functional properties are created when no condition exists
Change-Id: I9ced2e520d2f97e6655c9417970b3e976d78fef4
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ability to define a delay to marking a tach sensor as functional
when it transitions from a nonfunctional state. Essentially this gives
the option to wait a given amount of time that a tach sensor must be
within the allowed deviation before being updated to functional.
Default functional delay = 0 seconds
Tested: Current fan definition values function the same
Change-Id: I58bf70d2335e27c06037b755cbee8dae81528a5a
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class contains the trust groups, and is the interface
for asking if a sensor value can be trusted or not.
It will also start and stop timers on all sensors in the same
group as the timer in question whose trust value just changed.
This class will be used by the Fan class in the speed change
callback function to check if a sensor is trusted before
analyzing its value.
Change-Id: I134be095b6b5222f7bc0e457078cf01f75a36219
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
|
|
This commit contains the data that will be used by
the monitor code.
The generated.cpp file will later be generated during
the build by a python script.
Change-Id: I4dc4552ae8e58cd27478416888dd3363e7c2bf3f
Signed-off-by: Matt Spinler <spinler@us.ibm.com>
|
