summaryrefslogtreecommitdiffstats
path: root/monitor/tach_sensor.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add tach sensor functional delayMatthew Barth2018-03-011-0/+2
| | | | | | | | | | | | | | 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>
* Add target interface for fan monitorLei YU2018-02-261-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | 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-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Set tach sensor to functional on startMatthew Barth2018-01-301-36/+39
| | | | | | | | | | With the addition of a functional state for each fan rotor tach sensor, these should be set to functional on each power on. This is done during fan monitor init mode when no monitor is done and then again once monitoring mode begins. Change-Id: I3c73c1be5f912c7cee8499f47cc799ac3c20983b Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use setFunctional when tach sensor is constructedMatthew Barth2018-01-231-2/+1
| | | | | Change-Id: I32e30dc8f659172026258ca533099404c90aebbc Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* All sensors should return a target speed valueMatthew Barth2018-01-181-1/+9
| | | | | | | | | | | | | All tach sensors associated with a fan should return a target speed sensor from its getTarget function. In the case where a target speed sensor does not exist for the tach sensor, it retrieves and returns the target speed value from the fan where the fan finds the target speed value from a tach sensor the fan contains that provides it. Resolves openbmc/openbmc#2784 Change-Id: Iea5561b0aad6942be52af262c7255c60e5e75c7a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set tach sensor inventory functional stateMatthew Barth2017-12-051-1/+9
| | | | | | | | | | | At startup, initialize the functional state of each tach sensor to true and then update the inventory's functional state to match the tach sensor's functional state. Resolves openbmc/openbmc#2629 Change-Id: If608e4c044d9eeaa3dbdafa22bc89327e323c9a8 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add functional property for each tach sensorMatthew Barth2017-12-051-1/+22
| | | | | | | | | | | | Each fan's tach sensor creates a child inventory object under the fan's inventory path containing the sensor's functional state. This child inventory object path is the fan's path plus the tach sensor's defined id. i.e.) /xyz/openbmc_project/inventory/system/chassis/motherboard/fan0/fan0_0 Change-Id: I0fe5000eadbe55d60b475ccad700b0264ed0ac75 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* monitor: Add tach sensor trust group classMatt Spinler2017-10-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The trust::Group class is an abstract base class that introduces the concept of knowing if a tach sensor reading can be trusted or not. If it isn't trusted, then it shouldn't be used when calculating if the fan is considered functional or not. It's a group because it supports groups of sensors all having the same trusted status. For example the first use case is a group of sensors cannot be trusted when all of their readings are zero. A group may of course just have 1 sensor in it if required. The class also provides the functionality to start and stop the timers that are used to consider a sensor faulted. The timers would be stopped when a group moves to untrusted, and started when it goes back to the trusted state. Derived classes provide the functionality that actually determines the trust value. The constructor takes the list of sensor names that should be in the group. After the TachSensor classes have been constructed, the registerSensor(sensor) function must be called to add the sensor objects to the group. The checkTrust() function is used to calculate the trust status of the group. Change-Id: Ib4b871c6a186105028d1cc186c49611fb0608325 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Remove static systemd match callbacksBrad Bishop2017-08-031-28/+4
| | | | | | | | Replace static systemd match callback wrappers with lamba methods. Change-Id: Ib8471478824d87483a60f527d29aa2d35ccb833f Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Use sdbusplus::bus::match::rulesBrad Bishop2017-08-031-5/+2
| | | | | Change-Id: I96ed7de07acfc864c497a0130c3e5afab579d21d Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Allow missing sensorsBrad Bishop2017-08-031-5/+15
| | | | | | | | Don't count sensors that don't exist as nonfunctional. Let some other application decide if missing sensors are a problem or not. Change-Id: Ie3d438c92df16bfd86ddc86db8a9dd143bf2cfb0 Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Remove getServiceBrad Bishop2017-08-031-12/+0
| | | | | | | Remove getService from tach_sensor as it is no longer used. Change-Id: I568afb502379e05e85685d279033ab198c3cc91f Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Use common wrapper methodsBrad Bishop2017-08-031-32/+5
| | | | | | | | Replace the implementation of readProperty with a call to the common property accessor in sdbusplus.hpp. Change-Id: Ic4ba75bad7458a99f3e29c9235e1a54ae62286fe Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
* monitor: Avoid Target interface for mapper queriesBrad Bishop2017-07-111-1/+3
| | | | | | | Avoid asking the mapper for the Target interface on sensors that do not have it. Change-Id: I43f61c98291cc15d7daf43d2b01c6b7fa4edfa62
* phosphor-fan-presence elog error exception.Dinesh Chinari2017-06-281-3/+10
| | | | | | | | Implemented elog exception for phosphor fan presence, replacing runtime_errors. Change-Id: I70465060838b2cbaeadccf84ed5924e222ac59e3 Signed-off-by: Dinesh Chinari <chinari@us.ibm.com>
* Use unique_ptr for sd_event object wrapperMatt Spinler2017-05-111-1/+1
| | | | | | | | Convert the sd_event object wrapper from a shared_ptr to a unique_ptr. Requires a new header file. Change-Id: I868a9e88ed93878c2e0bb12e58f8d3a604510da0 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add Timer support to TachSensorMatt Spinler2017-05-111-3/+12
| | | | | | | Add a Timer object to the TachSensor class Change-Id: I419b5712de9e8e94f2a08de84d13170e44c33c7a Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Add dbus support to TachSensorMatt Spinler2017-05-111-1/+189
| | | | | | | | | | | | | | | TachSensor will match on properties changed signals for the Value and Target properties. When these occur, it will load in those properties and then tell the Fan class there was a change. Also, TachSensor will read in the Target property during construction so it will have a valid value to check against right away. Change-Id: I2dc2cacf5804826c6b0e0ea91196cbdaa4d5b893 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Fan and TachSensor class introductionMatt Spinler2017-05-111-0/+49
A Fan object has one or more TachSensor objects. The TachSensor class is used to keep track of the the actual and expected speeds. It only tracks expected speeds if the _hasTarget attribute is true. Future commits will add more functionality. Change-Id: I9bb5fac39f25c5c31c18457ebedf82838fcf6641 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
OpenPOWER on IntegriCloud