summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace tuple with struct for trust sensor groupMatthew Barth2018-03-012-12/+16
| | | | | | | | | | | To simplify sensor and trust access, utilize a struct in place of a tuple for storing the trust group sensors and their inclusion in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: Ifd5cf5d0540a3b2028ccf74e725d8ddd11982aee Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Generate sensor to trust associationMatthew Barth2018-03-013-21/+34
| | | | | | | | | | | | | | | | | Each sensor listed to be associated with a trust group is defined to either be part of the trust group or just affected by the results of the trust group. This is denoted by defining an "in_trust" boolean attribute that will include the sensor in the trust group for determination of trust when true, otherwise only be included in the resulting trust affect when defined as false. When no "in_trust" attribute is given, the sensor is defaulted to be included in the trust group determining trust. Tested: Current trust group associations & reactions are unchanged Change-Id: I717074bc1a32a07dc59f172a4c823c7e2bb84f8c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* optimize: Tach sensors as shared pointersMatthew Barth2018-03-015-13/+12
| | | | | | | | | | | | | The fan and trust group objects should utilize shared pointers to the tach sensor objects. This allows optimizing the storage of additional attributes associated with the tach sensors. e.g. An attribute to declare which sensors should be included in the trust determination. Tested: Current trust group associations & reactions are unchanged Change-Id: I249cc7debf467e8275fae7fa157ce97078b40802 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add target interface for fan controlLei YU2018-02-265-8/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Current fan control assumes the use of the FanSpeed interface for fan targets. For fans controlled by pwm, FanPwm interface is added. This commit adds "target_interface" config parameter, so that user can specify the interface for the fan targets. E.g. - inventory: /system/chassis/motherboard/fan0 cooling_zone: 0 cooling_profile: air sensors: - fan0 target_interface: xyz.openbmc_project.Control.FanPwm The config is optional and defaults to FanSpeed, so the current code will not be affected. Tested: Use this config on Romulus, ensures the fan control sets target on FanPwm interface and works fine. Change-Id: I73adccaa770d657b5d7aaeb307917f89588524de Signed-off-by: Lei YU <mine260309@gmail.com>
* Add target interface for fan monitorLei YU2018-02-266-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | 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-266-2/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-304-71/+78
| | | | | | | | | | 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>
* Support properties of type stringMatthew Barth2018-01-292-8/+32
| | | | | | | | | | | | Properties used within set speed events may be of type string to trigger an action. These should be handled where the defined type attribute is given as 'std::string' and a parsed value is an instance of python str type. Resolves openbmc/openbmc#292 Change-Id: Ib188e7abc212062a1c61950abaa28434a4726521 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>
* Remove getTargetSpeedMatthew Barth2018-01-232-21/+2
| | | | | | | | The getTargetSpeed function is no longer needed. The tach sensors are used to get the target speed. Change-Id: I5f82b0c3e8104203e2700b22a5488cf63673d181 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* All sensors should return a target speed valueMatthew Barth2018-01-184-28/+44
| | | | | | | | | | | | | 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>
* Decreases allowed based on all groupsMatthew Barth2017-12-143-30/+58
| | | | | | | | | | | | | | | For speed decreases to occur, all sensor groups involved with setting a net decrease delta must be below their given t-control low values for the associated zone. This handles the case where one or more sensor groups' temperatures stabilize above their t-control low value, but one or more other sensor groups' temperatures are below their t-control low value which would result in speed decrease requests that could eventually lead to fan speed oscillations. Resolves openbmc/openbmc#2710 Change-Id: I382de5d3f9c3e631a332d49dfcb06e705ff6fc17 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add path to trace for missing propertyMatthew Barth2017-12-111-1/+2
| | | | | | | | When a property can not be found after receiving a property changed signal include the path for the property on the journal entry. Change-Id: Ie0151b943914e02d38bf89760f8a16dc530aa89e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use Ceiling speed as request baseMatthew Barth2017-12-111-0/+5
| | | | | | | | | When determining the request base speed for speed decreases, the current ceiling speed should be used when the request base speed is above the ceiling. Change-Id: Iefc2f1669b853e099fbda15dc8c8983f5f1f269a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set tach sensor inventory functional stateMatthew Barth2017-12-052-7/+12
| | | | | | | | | | | 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-054-2/+47
| | | | | | | | | | | | 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>
* Update fan inventory methodMatthew Barth2017-12-054-52/+60
| | | | | | | | | Use the methods provided within sdbusplus.hpp to update fan inventory along with prepping inventory to be updated for each fan rotor sensor's functional state. Change-Id: I7d3026d289b1dd22cd4e7b4457c4d4396309c0b5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update string compares on signal messagesMatthew Barth2017-12-041-4/+3
| | | | | | | | Resulting from a code review, remove the use of strcmp when comparing a string to a const char* Change-Id: Idcd3f99bf7ca0151f5f1b97c7ccc54d6e8c56f8e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update trust group sensor timer startMatthew Barth2017-11-271-2/+5
| | | | | | | | | | | | | | Trust group sensors' timers should only start when the sensor is currently functional and its target and input do not match. This handles the case where a sensor within a trust group does not get a target set resulting in both the target and input to be zero. At anytime a sensor's target and input are equal, the timer to mark them as nonfunctional should not start. Change-Id: I8e4fd33a5bcbd25854e5954b41646127982eedd3 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Disable zone move constructorMatthew Barth2017-11-211-1/+1
| | | | | | | | To ensure no future enhancements attempt to store a reference to the zone object that are used to allow zone function calls. Change-Id: I0dc266445abdbce86b5fd505589aa96b7730c29a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Fix indentation from review commentMatthew Barth2017-11-171-3/+3
| | | | | | | https://gerrit.openbmc-project.xyz/#/c/7574/7/control/fan.cpp@89 Change-Id: I572093d1bbe636f5fb4f021b3b8478de19acc673 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Use in place init of event dataMatthew Barth2017-11-172-17/+8
| | | | | Change-Id: Ia56acbeaa89423060e65e50eff8accffec5a4631 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Remove empty service nameMatthew Barth2017-11-172-1/+37
| | | | | | | | | | Before refreshing the service names and states for a group, the empty service name should be removed if it exists. An empty service name may exist where upon startup, a particular service was not found for a member or members of a group. Change-Id: I15d224231bb9db0823866393ec1776f793a3c126 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Refresh service states for a groupMatthew Barth2017-11-173-0/+41
| | | | | | | | | | | Prior to an action resulting from missing service owners, all of the services for a group should be refreshed to ensure they are in the most up-to-date state. Ensuring the service states are current allows the action to be correctly taken since owners of services could change at anytime. Change-Id: I59c59c6fcf456fa9c0a733d6406c90ea11f6e2b2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Init zone target speed to current target speedMatthew Barth2017-11-173-1/+36
| | | | | | | | | | | | | | Whenever fan control (control mode) is started, the target speed for each zone should be initialized to the currently set target speed. In the case where a watchdog has triggered the fans to full speed and the target speed does not reflect this, the proper set of set speed events should be configured. In this case, an event could be defined to use the current tach feedback to adjust the target speed prior to account for the real state of the fan speeds. Change-Id: I538644ffc83a6e01469174304d393c889038d066 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set fan speed on missing owner actionMatthew Barth2017-11-172-0/+35
| | | | | | | | | | Sets the zone's fan speeds to a given speed when any service owner associated with an event group is missing. Once all the services are functional and providing the event data again, active fan speed changes are allowed. Change-Id: I318f6114c8d0392432c421f803db07a4683d1097 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set floor to default on missing owner actionMatthew Barth2017-11-174-5/+60
| | | | | | | | | | | | | | An action to set the fan floor speed to the defined default fan floor speed when any services associated to a given group of sensors have terminated. Once those services are functional and providing the sensors, the fan floor is allowed to be set normally again. i.e.) For fan floor speeds based on an ambient sensor, if the service providing the ambient temperature value from the sensor terminates, the default floor for the zone is used as the fan floor speed. Change-Id: I2d58cc9b31051e6b8e5e798c0a736f58f5efe5b1 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Allow timers & embedded actions within an actionMatthew Barth2017-11-171-28/+64
| | | | | | | | | Add support for timer parameters to action functions along with recursively build action functions that are a parameter to an event action. Change-Id: Ic126c8dfc85d5ede5f53034262f8910913e4cdd4 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Modify generating event actionsMatthew Barth2017-11-171-15/+10
| | | | | | | | Move to constructing the entire event action parameter string within the python code in prep for additional special parameters. Change-Id: I517ad859813e348cd6781cc9be11ab92fa6cac09 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Action that creates/starts a timerMatthew Barth2017-11-172-0/+85
| | | | | | | | Another action is provided to the timer and is performed when the timer expires. Change-Id: Ie6a06b0d56272a158d74bf03287183f07f00aed8 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add timer event managementMatthew Barth2017-11-173-4/+121
| | | | | | | | | | Events defined to have timers require the ability to find a timer, add a timer to the event, and removing a timer event entirely. These event timers are intended to allow actions based on the event to be delayed or recurring based on the timer defined. Change-Id: Ieaf26f031c5e5aac9472e92354bfb76392642cb4 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add timer type for set speed event timersMatthew Barth2017-11-173-4/+10
| | | | | | | | This is the first step towards allowing timer driven and/or wrapped actions where the timer interval and type will be defined by the user. Change-Id: If008fda5a2b73117e869f93223e0bfe61290f858 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Fill in NameOwnerChanged signal supportMatthew Barth2017-11-172-3/+38
| | | | | | | | | | A NameOwnerChanged signal message provides three strings containing the service name that has changed along with its old service owner name and new service owner name. These names are then passed along to the handler to find/update the group associated with the changed owner name. Change-Id: I7d67883b010fec5b282bd00a4dcc29629486af00 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Generate selected handlersMatthew Barth2017-11-171-48/+125
| | | | | | | | The available event handlers are listed within the events yaml and would be selected per event. Change-Id: Ia393009b3a10b6f47f5de9a0e6d44f804576f05a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Set/update a service name owner for a groupMatthew Barth2017-11-173-0/+50
| | | | | | | | | Adds a service name associated with a group when the group or given service name is not found within the map of services otherwise updates the service name owner associated with the group. Change-Id: I602ddaa7e06e354e01ea70d6c5c0a45e74a14e99 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Stub NameOwnerChanged signal supportMatthew Barth2017-11-172-0/+87
| | | | | | | | | NameOwnerChanged signals will be used within fan control to configure set speed events for when services providing parameters to the fan control application have unexpectedly terminated. Change-Id: I04f3c7ca2842732e33dc94b0280ad4483f7f1286 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Update event initializationMatthew Barth2017-11-176-151/+199
| | | | | | | | | | | | | | | | Using a null dbus message to the event signal will perform the necessary steps to initialize the event parameters using the given signal handler's function directly. i.e.) In the case for subscribing to PropertiesChanged signals, initially the given property must be read. When the PropertiesChanged signal struct is given a null message, it finds the property, reads the value, and then can perform the given signal handler function directly. This produces the same functional path as receiving a PropertiesChanged signal containing the property value within the message. Change-Id: I35575cfff66eb0305156be786cb1f5536d42bb1c Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Fix up InternalFailure to include metadataMarri Devender Rao2017-11-164-11/+44
| | | | | | | Scope is to add missing logs for InternalFailure errors Change-Id: I12c958127c1303fba0057914682e651457a0e547 Signed-off-by: Marri Devender Rao <devenrao@in.ibm.com>
* Generate selected match strings and signalsMatthew Barth2017-11-074-83/+185
| | | | | | | | | The available matches and their associated signals are now listed within the events yaml and can be added to the list of matches to register for per event. Change-Id: I65f657038afe7c68a421adb4820ea09e275be06d Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* DOC ONLY: Add preconditions section descriptionMatthew Barth2017-11-061-0/+6
| | | | | Change-Id: I260319dbfc4cb87bfed8fd724ffc4978f34e7325 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Spelling fixesGunnar Mills2017-10-253-4/+4
| | | | | | | | | Spelling errors found using github.com/lucasdemarchi/codespell A tool to fix common misspellings. This tool is licensed under GNU General Public License, version 2. Change-Id: Iefb2ad70d313a4800cd413c7c2e5e2154bec49fb Signed-off-by: Gunnar Mills <gmills@us.ibm.com>
* monitor: Start checking tach trustMatt Spinler2017-10-113-2/+27
| | | | | | | | | The Fan class now uses the trust::Manager class to ask if a sensor value is trusted before analyzing its value against the upper and lower limits. Change-Id: I81dd468877873ba84753d76395b4a59129824c0b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Update YAML parser to handle trust groupsMatt Spinler2017-10-113-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* monitor: Update example YAMLMatt Spinler2017-10-111-1/+21
| | | | | | | | Update the YAML documentation with sensor trust information. Change-Id: Ia5407b079b5dcfbd4063cec8dbba032fefa11b6b Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Add trust manager classMatt Spinler2017-10-112-0/+151
| | | | | | | | | | | | | | | 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>
* monitor: Add NonzeroSpeed trust group classMatt Spinler2017-10-111-0/+63
| | | | | | | | | | | | | | | | | This class provides the ability to only trust the sensors in the group if at least one of them has a nonzero speed. It is being used for a system where the tach values for a set of rotors are reported as zero by the fan controller hardware when the other rotor on the fan is moving to a new target speed. As all the fans are set to the same speed at the same time, the rotors in question all report as zeros at exactly the same time, and this is then used to know when the values cannot be trusted. Change-Id: I29a014014bc8455287f90e5b573a856814331a53 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* monitor: Add tach sensor trust group classMatt Spinler2017-10-113-1/+239
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Move timer ops into TachSensorMatt Spinler2017-10-022-8/+27
| | | | | | | | | Upcoming commits will touch the TachSensor timer outside of the Fan class, and it will be cleaner to encapsulate the operations in TachSensor. Change-Id: I8584c44eb5dbe6bb93191a006d20dfc37596eeb3 Signed-off-by: Matt Spinler <spinler@us.ibm.com>
* Allow no parameter action functionsMatthew Barth2017-09-281-22/+41
| | | | | | | Action functions are not required to have parameters. Change-Id: I04bf8294d9be9141cc7d8d3183628c94b777154a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Create set request speed base action functionMatthew Barth2017-09-283-166/+235
| | | | | | | | | | | | | | | | | This action function is intended to allow the base request speed to be set to the max value from a group of properties. The base request speed is the base speed used in requesting a new target speed. By default, the base request speed is the current target speed. For example, this action can be used to set the base request speed used in calculating a new target speed to be based on the max tach feedback speed from a group of fans instead of the current target speed. Adding this action function requires the other non-template functions to also be slightly modified due to linker errors. Change-Id: Ibbe9b33678b10cb49466174088a587b27bf56d62 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
OpenPOWER on IntegriCloud