summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Generate InterfacesRemoved signal eventsMatthew Barth2018-03-301-4/+12
| | | | | | | | | | | | | | | | | | | | In the case that an interface containing a property used within an event is removed from dbus, that event can subscribe to the InterfacesRemoved signal. When an InterfacesRemoved signal is received by fan control, the corresponding interface (and all associated properties) is removed from the cache used by all events. *Note: This area of signal subscription/handling code generation is intended to be re-worked under openbmc/openbmc#2911. This is the reason for supporting a different yaml layout for the InterfacesRemoved signal. Tested: Generated code constructs InterfacesRemoved signals correctly Resolves openbmc/openbmc#2223 Change-Id: Idc3e8db4e7dc07a2bb6898d3cc30ab775362dd35 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add InterfacesRemoved signal handlingMatthew Barth2018-03-304-0/+129
| | | | | | | | | | | | | | | When an InterfacesRemoved signal is received for a subscribed object path, each interface returned is checked against the interface which was defined for each object on the event. When these are equal, the interface (and all associated properties) are removed from the shared cache of event properties. Tested: Manually added an InterfacesRemoved signal Verified interface was removed from object path in cache Change-Id: I348d82f14e0cfba2b18a81a9f54c6cb06b586797 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Minimize service name mapper lookupsMatthew Barth2018-03-122-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Retrieve the service names from the cached dataset within the zone for a path and interface, updating the cache when not found. This is used when initializing property values and service name owners. Additional performance enhancements to use `GetSubTree` prior to processing a set speed event will be included under openbmc/openbmc#2911. This will keep unnecessary `GetSubTree` lookups from occurring for paths/interfaces that don't exist to further improve upon initializing properties fan control is defined to use. Tested: First path updates service name cache for all paths sharing the same interface First missing interface on a path updates service name cache for all paths sharing that interface Verify mapper lookups for X number of paths sharing the same interface is reduced to (X-(X-1)) NameOwnerChanged events read/update the same set of service name cache Change-Id: Ia235b36ba5ae8cda38342d7521f3d87080c2970a Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Get a property without service name lookupMatthew Barth2018-03-121-0/+40
| | | | | | | | | | | Expand on the current getProperty functions to allow a service name to be passed in so a mapper lookup is not necessary. Tested: A property value is read from a message where the service is given Change-Id: Ia0450163744c9f89a26a053ec2cfb44ae761426d Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Cache service names for paths and interfacesMatthew Barth2018-03-122-0/+122
| | | | | | | | | | | | | | | | To lookup a service name for a given path and interface, use GetSubTree to retrieve all the service names from the root path for the interface and add each entry to a cached dataset. Tested: Check that a missing interface's service is added Check that a missing path that exists has its service added Inspect all missing paths for an interface are added Inspect missing interfaces are added to existing service Returned service name matches the service for a path/interface Change-Id: I6db05479e825350198896b2e237882f7ebc58d51 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add GetSubTree method for single interfaceMatthew Barth2018-03-061-0/+38
| | | | | | | | | | | | Perform a GetSubTree mapper call and return the mapper response structure as is for a single interface over a given path subtree depth. Tested: Returned subtree structure matches mapper structure for an interface Returned subtree data matches mapper data for an interface Change-Id: If6b66433a331ac20633ac99c458eb5edb653bff2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Make event actions optionalMatthew Barth2018-03-061-2/+5
| | | | | | | | | | | | | | | | | | Event actions should be made optional for events that only require subscribing to group signals. This is in preparation for separating signal and timer based event actions. A use case would be where one event can be used to subscribe to signals that update cached property values without performing an action, and another timer based event performs an action based on those property values the signal event provides. Tested: Events without an action are generated correctly Events without an action are handled correctly and run no action Change-Id: I757a82ce6c45ac637ce7cea8f82a62b98b600e3e Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Parse a list of groups with zone conditionsMatthew Barth2018-03-061-198/+219
| | | | | | | | | | | | | | | Set speed events can use a list of groups associated with its actions where each group defines what zone conditions the group should be included in actions. Tested: List a single group within an event List two groups within an event with different zone conditions List two groups within an event in the same zone conditions List more than two groups with different zone conditions Change-Id: Ifba30e116f92d945f8812c15e856a5e772e077f2 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Handle timer expiration on state changesMatthew Barth2018-03-011-19/+17
| | | | | | | | | | | | | | | | | | Update to start all tach sensor functional state change timers on a fan where the corresponding state and inventory is updated when the timer expires. Only start the timer in nonfunctional mode when a tach sensor is out of range and is currently functional and start the functional mode timer when its in range and currently nonfunctional. Tested: Tach sensors are marked nonfunctional as normal. Tach sensors are updated to functional after 5sec(yaml test value) Nonfunctional timer is cancelled if fan returns within spec Functional timer is cancelled if fan returns out of spec Change-Id: I88622d07d8713f88e8070940a4bd96046a053fb5 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Define a mode for tach sensor timerMatthew Barth2018-03-014-14/+67
| | | | | | | | | | | | | | Use a single timer on the tach sensors for delaying both nonfunctional and functional state changes by declaring what mode the timer is in. Since a fan is either transitioning from a functional state to a nonfunctional state or vice-versa, enabling the timer in the mode requested allows the user to define a delay for both of these transition states. Tested: Current nonfunctional timer delay operates the same Change-Id: I0c165355d41d27e1906918953e5226968062ee16 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* Add tach sensor functional delayMatthew Barth2018-03-016-4/+21
| | | | | | | | | | | | | | 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>
* NonzeroSpeed: Check trust determination sensorsMatthew Barth2018-03-012-6/+11
| | | | | | | | | | | | Only include defined trust determination sensors in checking the group trust. Tested: Current trust group associations & reactions are unchanged Combination of sensors included and excluded in trust determination Change-Id: I0f610b2910ffda849871a9ac9be95f2c056d8248 Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
* 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>
OpenPOWER on IntegriCloud