Support to accumulate PWM of different controllers for same sensor

Description:
1. Add one property: accumulateSetPoint in zone of fan table that could
be used to enable accumulation of output PW

Support to accumulate PWM of different controllers for same sensor

Description:
1. Add one property: accumulateSetPoint in zone of fan table that could
be used to enable accumulation of output PWM of different controllers
with same sensor.

2. Add one property: checkHysterWithSetpt in pid info of fan table to
select to compare current input and setpoint to check hysteresis.

3. The purpose of accumulate the stepwise output and PID output for
one sensor is that the setting of stepwise could use to prevent
the fan speed from suddenly increasing from a very low speed to a
very high speed due to reaching the setpoint.

Use stepwise before setpoint could also keep the PWM steady at
low ambient temperature.

Design:
1. Search "accumulateSetPoint" field in fan table.
If the value was true, accumulate the output PWM of different
controllers with same profile name.

2. Support two method to calculate PID output that could be chosen by
setting the "checkHysterWithSetpt" to true in pid info of fan table.

If the flag was set to true, it won't calculate PWM output if the
input lower than setpoint.

Test Case:
1. Check the output PWM of different controllers with same profile
name could be accumulated - pass.

2. Set "checkHysterWithSetpt" to true and check PID output would not be
calculated if the input temperature was lower than setpoint - pass.

Please see more details in gist:
https://gist.github.com/DelphineCCChiu/a6170d3e1a12fc4ee76fad324382fba3

Change-Id: I9f38f250d72545784c6c11be2fde7d45f0b385c4
Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@wiwynn.com>

show more ...

Add MissingIsAcceptable feature to avoid failsafe

This is a partial implementation of the ideas here:
https://github.com/openbmc/phosphor-pid-control/issues/31

A new configuration item is supported

Add MissingIsAcceptable feature to avoid failsafe

This is a partial implementation of the ideas here:
https://github.com/openbmc/phosphor-pid-control/issues/31

A new configuration item is supported in the PID object, named
"MissingIsAcceptable" (for D-Bus) or "missingIsAcceptable" (for the old
config.json). The value is an array of strings. If these strings match
sensor names, those sensors will be flagged as "missing is acceptable",
that is, they can go missing and the zone will not be thrown into
failsafe mode as a result.

This can be handy for sensors that are not always available on your
particular machine. It is independent of the existing Availability
interface, because the decision to go into failsafe mode or not is a
property of the PID loop, not of the sensor itself.

If a PID loop consists of all sensors that are missing, the output
will be deemed to be the setpoint, thus essentially making the PID
loop a no-op. Now initializing sensor values to NaN, not zero, as zero
is not a good default if PID loop is margin, undoing a bug I made:
https://gerrit.openbmc.org/c/openbmc/phosphor-pid-control/+/38228

Tested: It worked for me. Also, added a unit test case.

Change-Id: Idc7978ab06fcc9ed8c6c9df9483101376e5df4d1
Signed-off-by: Josh Lehan <krellan@google.com>

show more ...

Implementing the TempToMargin feature

Wrapping the input name std::string in a new structure SensorInput, so
that the TempToMargin information can be cleanly carried along with
it, all the way down

Implementing the TempToMargin feature

Wrapping the input name std::string in a new structure SensorInput, so
that the TempToMargin information can be cleanly carried along with
it, all the way down to the PID input processing layer where it is
needed. This allows the conversion to be done just-in-time before the
temperature reading is interpreted, minimizing the blast radius of
this change. Nonetheless, because of the type change, there was a
somewhat large blast radius to implement this feature.

The design, and the documentation, is already here:
https://github.com/openbmc/phosphor-pid-control/issues/23

Tested: Added unit tests for JSON parsing and for proper execution
of the TempToMargin feature. They pass. Ran it locally, on our
appropriately-configured system, and it seems to work for me.

Change-Id: I598ba485195aaa70c26e91a1da3ab88fff8c3a4c
Signed-off-by: Josh Lehan <krellan@google.com>

show more ...

Set failsafePwm by pid configuration

<motivation>
Current phosphor-pid-control service supports one zone with
one failsafepwm. However, for some platforms there are
different pluggable cards in a zo

Set failsafePwm by pid configuration

<motivation>
Current phosphor-pid-control service supports one zone with
one failsafepwm. However, for some platforms there are
different pluggable cards in a zone. Different combinations
may require different failsafe pwm settings. Why not just
use one zone failsafepwm for all the combinations? because if
we take power consumption or acoustic into consideration,
we will find that not all the cases need the same high
failsafepwm. Each case just need high enough failsafepwm
to cool down the system in that condition.

For example
case1: zone0 : gpuA card + motherboard in zone0
=>requires failsafepwm = 80

case2: zone1 : gpuB card + motherboard in zone0
=>requires failsafepwm = 60

In order to solve the problem described above , we propose
the design that. Each pidloop has its own failsafepwm.
The final failsafepwm will be calculated during building
zone process. The detailed design concept is described in
design concept section.

<design concept>
a zone has several pid loops, each one has its own pid
failsafe pwm defined in its configuration.

The calculation flow goes as below:
1.Take failsafepwm of the pidloops and the zone from the configuration
files, if any is missing , set it to zero.
2.Take max value of (zone failsafepwm and pid loops failsafepwm).
3.If the max value from 'step 2' is zero indicates none of failsafepwm
is configured, set it to default setting 100%.

<note>
1.this is intended for dbus configuration method, since one zone
may have different pidloops from different pluggable boards
entity json, but this design also works for static configuration
method, therefore, the zone with different boards will need
different failsafepwm.
2.keep it back compatible with original design , also take zone
failsafepwm into calculation.

Working example as below

Case1
Zone0:
zone0 pidloop failsafepwm = 60
gpuA pidloop failsafepwm = 70
Motherboard failsafepwm = 40

=>final failsafepwm = 70

Case2
Zone0:
zone0 pidloop failsafepwm = 60
gpuB pidloop failsafepwm = 80
Motherboard failsafepwm = 40

=>final failsafepwm = 80

Change-Id: I5aa1c6a7108f4520f41de5d8eba3075d021bbe79
Signed-off-by: ykchiu <Chiu.YK@inventec.com>

show more ...

Support derivative term in PID algorithm and support to set cycle interval time from fan table

1. Support to calculate derivative term in PID algorithm.
2. Add two properties: cycleIntervalTimeMS an

Support derivative term in PID algorithm and support to set cycle interval time from fan table

1. Support to calculate derivative term in PID algorithm.
2. Add two properties: cycleIntervalTimeMS and updateThermalsTimeMS
in fan table that could be used to decide "time interval of PID control loop"
and "time interval to update thermals' cached value".

Tested:

- PID algorithm:
1. Check pid-control-service could calculate output PWM
according to the fan table.

[Test log]
root@greatlakes:~# systemctl status phosphor-pid-control -l
* phosphor-pid-control.service - Phosphor-Pid-Control Margin-based Fan Control Daemon
Loaded: loaded (/lib/systemd/system/phosphor-pid-control.service; enabled; preset: enabled)
Active: active (running) since Fri 2018-03-09 05:09:35 PST; 1min 47s ago
Main PID: 3105 (swampd)
CGroup: /system.slice/phosphor-pid-control.service
`-3105 /usr/bin/swampd -c /usr/share/entity-manager/configurations/fan-table.json
...
Mar 09 05:10:29 greatlakes phosphor-pid-control[3105]: PID Zone 1 max SetPoint 3.75 requested by
PID_NIC_SENSOR_TEMP BMC_SENSOR_FAN0_TACH BMC_SENSOR_FAN2_TACH BMC_SENSOR_FAN4_TACH BMC_SENSOR_FAN6_TACH

- Cycle interval time:
1. Set cycleIntervalTimeMS and updateThermalsTimeMS
to 1000 ms in fan table
2. Check service would update thermal every second from debug log.

[Test log]
root@greatlakes:~# journalctl -u phosphor-pid-control --since "Mar 09 04:52:16"
Mar 09 04:52:16 greatlakes systemd[1]: Started Phosphor-Pid-Control Margin-based Fan Control Daemon.
...
Mar 09 04:53:28 greatlakes phosphor-pid-control[2795]: processThermals
Mar 09 04:53:28 greatlakes phosphor-pid-control[2795]: processFans
Mar 09 04:53:29 greatlakes phosphor-pid-control[2795]: processThermals
Mar 09 04:53:29 greatlakes phosphor-pid-control[2795]: processFans
Mar 09 04:53:30 greatlakes phosphor-pid-control[2795]: processThermals
Mar 09 04:53:30 greatlakes phosphor-pid-control[2795]: processFans

Change-Id: I04e1b440603c3ad66a1e26c96451992785da6fe6
Signed-off-by: Bonnie Lo <Bonnie_Lo@wiwynn.com>

show more ...

Make specific UNA sensors not trigger failsafe

By convention, sensors at some states like 'not present',
'power state not matching' are marked as 'unavailable' on dbus.
At such states, some specific

Make specific UNA sensors not trigger failsafe

By convention, sensors at some states like 'not present',
'power state not matching' are marked as 'unavailable' on dbus.
At such states, some specific sensors should not be considered as
failed and trigger pid 'failsafe'.

A typical example is when a system is powered-off, its CPU/DIMM temp
sensors are 'unavailable', these sensors should not be treated as
'failed' and trigger pid 'failsafe'. This is necessary for systems
whose Fans will keep working when the CPU is off.

This feature is configurable per sensor (valid on thermal sensors). It
can be enabled by setting the Pid controller option
"InputUnavailableAsFailed" to 'false' when one configuring the PID module
via entity-manager, or by setting the sensor option "unavailableAsFailed"
to 'false' when one configuring the PID module via JSON. (These options are
optional and default to 'true')

Tested:
1. On a Fan 'always-on' system, enabale this feature on CPU temp sensors,
poweroff the system, 'unavailable' CPU temp sensors do not trigger the
failsafe mode.
2. 'Unavailable' Fans still trigger the failsafe mode.
3. 'Unfunctional' or 'failed' sensors still trigger the failsafe mode.

Signed-off-by: Zheng Song <zheng.song@intel.com>
Change-Id: I1dd1d76466f43e7dcf51c161c96714f1bcfae88d

show more ...

drop struct keyword for non-packed objects

As a style decision, struct is often used with packed structures to
indicate they are used like C-structs. Cleanup this codebase to not use
the extra stru

drop struct keyword for non-packed objects

As a style decision, struct is often used with packed structures to
indicate they are used like C-structs. Cleanup this codebase to not use
the extra struct keyword throughout.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I2f83bb1989e4d1f2f843ba3e45fb82e04f0fa61c

show more ...

dbus: move debugPrint to util

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Idbea54f13527a4ca3108cc4dccbee07b7b3a7d34

sensors/zones: place in namespace and cleanup

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I527dbc8477a232945f696227a7b0b2adbee45175

conf: add ignoreDbusMinMax option

Add an optional field to the sensor configuration, s.t. it'll tell a
dbus passive sensor to ignore the MinValue and MaxValue properties from
dbus.

Signed-off-by: P

conf: add ignoreDbusMinMax option

Add an optional field to the sensor configuration, s.t. it'll tell a
dbus passive sensor to ignore the MinValue and MaxValue properties from
dbus.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: Ia6a8c802c2dc5bf41e5e860b21d7764cc09e6b6b

show more ...

rename away from RPM

The SetPoint output from a thermal PID is likely RPM, and that value is
then fed into a fan controller PID as the set-point (unit: RPM). This
does not have to be RPM, however.

rename away from RPM

The SetPoint output from a thermal PID is likely RPM, and that value is
then fed into a fan controller PID as the set-point (unit: RPM). This
does not have to be RPM, however. Continue renaming variables and
methods to remove the explicit unit-naming.

Signed-off-by: Patrick Venture <venture@google.com>
Change-Id: I570dee0c688338f9a458cac7123314717bee2b42

show more ...

sensors: ignore min/max in json for D-Bus passive sensor read

min/max values were meant to scale write to be PWM, but were
overloaded in commit 75eb769d351434547899186f73ff70ae00d7934a
to scale sens

sensors: ignore min/max in json for D-Bus passive sensor read

min/max values were meant to scale write to be PWM, but were
overloaded in commit 75eb769d351434547899186f73ff70ae00d7934a
to scale sensor read to percent as well. However currently the D-Bus sensors
built from JSON can only specify one pair of min/max values,so they
cannot be used for both read/write interfaces.

Fix the behavior by ignoring min/max in settings when building D-Bus passive
read interface and only read them from D-Bus.

Tested:
D-Bus passive sensor value is no longer scaled if there is no
MinValue/MaxValue specified.

Resolves: openbmc/phosphor-pid-control#14

Signed-off-by: Kun Yi <kunyi731@gmail.com>
Change-Id: I206bbe75c77e79f765eca76cfa015321dcba4aa7

show more ...

Expand conf namespace

Put rest of conf.hpp in the conf namespace. This is
largely a sed replace, and wrapping from_json in
conf namespace as it failed to build.

Change-Id: I9fe5c7b2fface44618c43af2

Expand conf namespace

Put rest of conf.hpp in the conf namespace. This is
largely a sed replace, and wrapping from_json in
conf namespace as it failed to build.

Change-Id: I9fe5c7b2fface44618c43af2367035afc39bcb64
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

s/minThermalRPM/minThermalOutput

The minThermalRPM is only an RPM by the fact that
that is the units of the PID. As the PID units can
be anything, change this to minThermalOutput to allow
for differ

s/minThermalRPM/minThermalOutput

The minThermalRPM is only an RPM by the fact that
that is the units of the PID. As the PID units can
be anything, change this to minThermalOutput to allow
for different units (i.e. percent).

Change-Id: Ic53fef1159ade5a413e5d519d407947f3023d8e3
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

dbuspassive: allow scaling

For tachs it is beneficial to deal in percent so that
multiple controllers can be used with different fan
types without having to recalculate. This starts using
the unused

dbuspassive: allow scaling

For tachs it is beneficial to deal in percent so that
multiple controllers can be used with different fan
types without having to recalculate. This starts using
the unused min and max fields to be able to scale readings.
Since max and min are commonly on the value interface, the
special value of <int64_t>::lowest() allows these to be gathered
from dbus instead of having to enter them manually.

Tested-by: Moved pid control to percent and printed
outputs

Change-Id: I9496eb92a18b68a7cd7f034d41d40ef5175c6974
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

conf change: sensors: read and write path rename

Rename the readpath and writepath for camelcase styling to make all
configuration variables consistent.

Change-Id: I33f475075c8f40cd2029a5c0bfda9508

conf change: sensors: read and write path rename

Rename the readpath and writepath for camelcase styling to make all
configuration variables consistent.

Change-Id: I33f475075c8f40cd2029a5c0bfda950846cd5d44
Signed-off-by: Patrick Venture <venture@google.com>

show more ...

conf change: rename zone variables

Rename the zone variables to make them camelCase as a step towards
making all configuration variables camelCase for consistency.

Note: This patchset requires a ch

conf change: rename zone variables

Rename the zone variables to make them camelCase as a step towards
making all configuration variables camelCase for consistency.

Note: This patchset requires a change to your yaml configuration if
you're using it, or libconfig if you're using it.

Change-Id: If9cf1d7eb8227d305a1625275f2f7082c0d6905a
Signed-off-by: Patrick Venture <venture@google.com>

show more ...

Move all floats to doubles

The code was developed initially around a pid loop implemented using
floats. Therefore, the code was converting back and forth between
double for sensor values as inputs

Move all floats to doubles

The code was developed initially around a pid loop implemented using
floats. Therefore, the code was converting back and forth between
double for sensor values as inputs and outputs from this PID loop.

Change-Id: I2d2919e1165103040729c9f16bb84fde3dd6b81b
Signed-off-by: Patrick Venture <venture@google.com>

show more ...

style: fixup naming of structures

Fixup naming of structures to UpperCamel.

Change-Id: I6a9bf0b954298089c85d3362e86cd95b3fc5b944
Signed-off-by: Patrick Venture <venture@google.com>

Add stepwise controller

This adds the ability to use stepwise curves alongside
pid control. This creates a base controller class that
pidcontroller and stepwise controller inherit from.

Note: Hyste

Add stepwise controller

This adds the ability to use stepwise curves alongside
pid control. This creates a base controller class that
pidcontroller and stepwise controller inherit from.

Note: Hysteresis to come in follow-on patch

Tested-by:
Created a stepwise controller and noticed that when it
crossed a threshold that it contributed to the pwm setting.

Change-Id: I6cf842f80eaccafc905d620970afe91e2092d568
Signed-off-by: James Feist <james.feist@linux.intel.com>

show more ...

add .clang-format

Change-Id: I6627b5569c2e0f730be7331403218b823a2c622f
Signed-off-by: Patrick Venture <venture@google.com>

Scripts and main daemon

This includes the scripts for the YAML parsing and the
main execution point.

Change-Id: If42154c621353b23370b63d4e58f6c75bca8b356
Signed-off-by: Patrick Venture <venture@goo

Scripts and main daemon

This includes the scripts for the YAML parsing and the
main execution point.

Change-Id: If42154c621353b23370b63d4e58f6c75bca8b356
Signed-off-by: Patrick Venture <venture@google.com>

show more ...