Add failsafe logger for zones

Tested:
...
Nov 23 21:40:06 tmddp10-nfd01.prod.google.com swampd[4893]:
Zone `0` is in failsafe mode.
With update at `fleeting0`: The sensor has bad readings.
Nov 23 21

Add failsafe logger for zones

Tested:
...
Nov 23 21:40:06 tmddp10-nfd01.prod.google.com swampd[4893]:
Zone `0` is in failsafe mode.
With update at `fleeting0`: The sensor has bad readings.
Nov 23 21:40:06 tmddp10-nfd01.prod.google.com swampd[4893]:
Zone `1` is in failsafe mode.
With update at `fleeting1`: The sensor has bad readings.
Nov 23 21:40:06 tmddp10-nfd01.prod.google.com swampd[4893]:
Zone `1` leaves failsafe mode.
With update at `hotswap_in_Input_Power`: The sensor has recovered.
Nov 23 21:40:06 tmddp10-nfd01.prod.google.com swampd[4893]:
Zone `0` leaves failsafe mode.
With update at `hotswap_in_Input_Power`: The sensor has recovered.
...

Change-Id: I2c296addb7ad117c03c04a27de91204796cda036
Signed-off-by: James Zheng <alphetis@google.com>

show more ...

Auto determine failsafe duty according sensor fail

- Auto determine the failsafe duty when sensor failed

example:
If PID config as follows, when "Die CPU0" sensor failed, fans in zone 0
will be set

Auto determine failsafe duty according sensor fail

- Auto determine the failsafe duty when sensor failed

example:
If PID config as follows, when "Die CPU0" sensor failed, fans in zone 0
will be set to 80%, when "DIMM0" sensor failed, since there is no
"FailSafePercent" setting in config, so set to zone's FailSafePercent
100%.
```
{
"Class": "temp",
...
...
...
"Inputs": [
"Die CPU0"
],
"Name": "CPU0 PID",
"FailSafePercent": 80.0,
...
...
...
"Type": "Pid",
"Zones": [
"Zone 0"
]
},
{
"Class": "temp",
...
...
...
"Inputs": [
"DIMM[0-9]",
"DIMM1[0-5]"
],
"Name": "DIMM CPU0 PID",
...
...
...
"Type": "Pid",
"Zones": [
"Zone 0"
]
},
{
"FailSafePercent": 100.0,
"MinThermalOutput": 0.0,
"Name": "Zone 0",
"Type": "Pid.Zone",
"ZoneIndex": 0
},
```

Tested:
If zone1 and zone2 into failsafe duty 40% =>
fan0_pwm | 1Dh | ok | 29.0 | 24.70 unspecifi
fan1_pwm | 1Eh | ok | 29.1 | 24.70 unspecifi
fan2_pwm | 1Fh | ok | 29.2 | 39.98 unspecifi
fan3_pwm | 20h | ok | 29.3 | 39.98 unspecifi
fan4_pwm | 21h | ok | 29.4 | 39.98 unspecifi
fan5_pwm | 22h | ok | 29.5 | 39.98 unspecifi

cpu0_nbm | 48h | ok | 7.79 | 36 degrees C

Let cpu0_nbm(zone0 and zone2) into failsafe which set failsafe duty as
100% =>
fan0_pwm | 1Dh | ok | 29.0 | 99.96 unspecifi
fan1_pwm | 1Eh | ok | 29.1 | 99.96 unspecifi
fan2_pwm | 1Fh | ok | 29.2 | 39.98 unspecifi
fan3_pwm | 20h | ok | 29.3 | 39.98 unspecifi
fan4_pwm | 21h | ok | 29.4 | 99.96 unspecifi
fan5_pwm | 22h | ok | 29.5 | 99.96 unspecifi

cpu0_nbm | 48h | ns | 7.79 | No Reading

Signed-off-by: Harvey Wu <Harvey.Wu@quantatw.com>
Change-Id: Iaf5ffd1853e5cd110a1ef66c7a1fd073bc894dda

show more ...

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 ...

zone: Add debug thermal/power interface

- Add xyz.openbmc_project.Debug.Pid.ThermalPower interface to
fanctrl/zoneX/pid dbus to record some datas in thermal/power
PID loop.

Tested:
```
busctl i

zone: Add debug thermal/power interface

- Add xyz.openbmc_project.Debug.Pid.ThermalPower interface to
fanctrl/zoneX/pid dbus to record some datas in thermal/power
PID loop.

Tested:
```
busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/CPU0_PID xyz.openbmc_project.Debug.Pid.ThermalPower
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
.ClassType property s "Temperature" emits-change
.Input property d 36.594 emits-change
.Leader property s "Die_CPU0" emits-change
.Output property d 4200 emits-change
.Setpoint property d 70 emits-change
```

Signed-off-by: Harvey Wu <Harvey.Wu@quantatw.com>
Change-Id: I6846c3878c2ca5eaeeb6eaf48aaf0f604a2beccf

show more ...

FanController: Use raw RPM as input to fan PID loop

The fan PID loop was wrongly using normalized RPM as input, instead of
raw RPM. This meant that the input RPM was between 0.0 and 1.0, the
wrong u

FanController: Use raw RPM as input to fan PID loop

The fan PID loop was wrongly using normalized RPM as input, instead of
raw RPM. This meant that the input RPM was between 0.0 and 1.0, the
wrong units, an unusable low value for RPM.

What's more, the inputProc() function used int64_t instead of double,
for an unknown reason, as the input and output of this function is
double. This integer truncation caused the normalized RPM to always be
zero, making this bug harder to notice.

Cleaned up the inputProc() function to always use double, and
correctly use the raw RPM.

I am really glad I had earlier added a feature to maintain the raw
unscaled value, along with the normalized scaled value, in the cache!
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-pid-control/+/36697

This made it easy to recover the raw value. Otherwise, this bug would
have been much harder to fix.

Tested: The RPM input values now use same units as the setpoint,
restoring proper fan PID loop operation, as logged in the new PID core
debugging feature here:
https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-pid-control/+/38087

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

show more ...

Add debug mode

Description:
1. Could enable debug mode by adding file: /etc/thermal.d/debugging.
$ mkdir /etc/thermal.d
$ touch /etc/thermal.d/debugging
$ systemctl resta

Add debug mode

Description:
1. Could enable debug mode by adding file: /etc/thermal.d/debugging.
$ mkdir /etc/thermal.d
$ touch /etc/thermal.d/debugging
$ systemctl restart phosphor-pid-control

2. Could record fans output PWM, chosen temperature, PID/stepwise output PWM in debug mode.

Design:
1. Create debugging file and restart service to enable debug mode.

2. Check if debug mode is enabled to output fans output PWM, chosen temperature,
PID/stepwise output PWM, and so on.

Test Case:
1. Enable debug mode and check logs: pass

Change-Id: I8527ebcb81e723298ba7e786b4501f986ebd439e
Signed-off-by: Bonnie Lo <Bonnie_Lo@wiwynn.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 ...

pid/zone: Adding unscaled to cache and logging

The "ReadReturn" structure, and the cache within DbusPidZone, have
been widened, to hold both the scaled and the original unscaled values
at the same t

pid/zone: Adding unscaled to cache and logging

The "ReadReturn" structure, and the cache within DbusPidZone, have
been widened, to hold both the scaled and the original unscaled values
at the same time. This allows logging to show both at once, and also
clears up confusion/bugs resulting from storing one or the other and
losing track of which was which.

Compatibility setValue() and getCachedValue() functions still
retained, so this will not break other sensors. These functions still
only take a single argument/return, which will be used for both value
and unscaled, indicating scaling is unknown or irrelevant to this
sensor.

Also, the PWM output of the PID loop appears in the log file,
conveniently right alongside the RPM input of the PID loop.

An output cache has been added to the zone interface, and, unlike the
input cache, use of it is optional. It is only to help populate the
logging, so subclasses are free to ignore it if they want.

Tested: In the logging files, I can see both PWM and RPM, and they are
consistent, showing how the PID loop is trying to update the PWM to
target the desired RPM.

Example: Here's /tmp/zone_0.log on my system
epoch_ms,setpt,fan0_tach,fan0_tach_raw,fan0_tach_pwm,fan0_tach_pwm_raw,bmcmargin_zone0,bmcmargin_zone0_raw,thermal_zone0,thermal_zone0_raw,failsafe
3097918,3818.42,0.748267,11224,0,0,0.724753,56.812,0.745098,62,0
3098022,3818.42,0.748267,11224,0.266666,67,0.724753,56.812,0.745098,62,0
3098132,3818.42,0.748267,11224,0.266666,67,0.724753,56.812,0.745098,62,0

Here's what we can now learn:
The desired setpoint is 3818 RPM.
The fan is at 74.8% of scale, which is 11224 RPM.
The written PWM, after the first PID loop pass, is a raw value of 67,
which is 26.6% of scale.
The first margin temperature is 56.8 degrees of margin, which is 72.4%
of scale.
The second margin temperature is 62 degrees of margin, which is 74.5%
of scale.
This zone is not in failsafe mode.
As you can see, this will be rather useful for PID loop tuning.

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

show more ...

For each zone log sensor name with max setpoint

Add sensor name that has the maximum setpoint for a PID zone.
Log a debug message when the sensor is changed.
The name is also added to the log file f

For each zone log sensor name with max setpoint

Add sensor name that has the maximum setpoint for a PID zone.
Log a debug message when the sensor is changed.
The name is also added to the log file for each log record.

Tested:
Override one CPU temperature sensor
busctl set-property xyz.openbmc_project.CPUSensor /xyz/openbmc_project/sensors/temperature/DTS_CPU1 xyz.openbmc_project.Sensor.Value Value d 82
Observed log message:
swampd[443]: PID Zone 0 max SetPoint 34.5546 requested by DTS_CPU1

Signed-off-by: Nirav Shah <nirav.j2.shah@intel.com>
Signed-off-by: Zhikui Ren <zhikui.ren@intel.com>
Change-Id: Ifc12cb9a106da1bf41dd35697210f74ba1b589db

show more ...

pid/zone: Restore PWM when fans returned to auto

This makes use of the improved write() interface, to allow the
PID-loop-determined PWM to be restored, when the fan is returned to
automatic mode.

W

pid/zone: Restore PWM when fans returned to auto

This makes use of the improved write() interface, to allow the
PID-loop-determined PWM to be restored, when the fan is returned to
automatic mode.

Without this fix, a fan set to manual mode, then manually set to a
different speed, would not properly return to the correct speed, when
transitioning back to automatic from manual.

This patch also adds a stub to allow the caller to learn the raw PWM
value written as output, another useful write() interface improvement.
Although not the topic of this change, it is included here, to avoid
later patch conflicts.

Tested: I can now correctly toggle between automatic, and manual, fan
control. Upon resuming automatic control, after a few seconds, the fan
PWM is now properly restored, to what the PID loop wanted it to be at.

Signed-off-by: Josh Lehan <krellan@google.com>
Signed-off-by: Jason Ling <jasonling@google.com>
Change-Id: I46fc65d6b931755d51093ea475c64cf5e3e6bacb

show more ...

use ZoneInterface pointers where Dbus aspect not important

The implementation of the ZoneInterface used is the DbusPidZone, however
using the ZoneInterface when the Dbus aspect is unimportant provid

use ZoneInterface pointers where Dbus aspect not important

The implementation of the ZoneInterface used is the DbusPidZone, however
using the ZoneInterface when the Dbus aspect is unimportant provides for
trivial support of other implementations.

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

show more ...

pid/zone: split zone interface into its own header

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

sensors/zones: place in namespace and cleanup

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

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 ...

rename RPMSetPoint to SetPoint

The PIDs were originally focused on collecting RPM set points from
thermal PIDs and then having fan PIDs use the highest value collected,
it doesn't need to be strictl

rename RPMSetPoint to SetPoint

The PIDs were originally focused on collecting RPM set points from
thermal PIDs and then having fan PIDs use the highest value collected,
it doesn't need to be strictly an RPM set point.

It does however need to be one type of value.

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

show more ...

stepwise: Add ceiling type

Add a stepwise ceiling type, this is used as a
upper clipping curve to limit the max output based
on a temperature sensor. This is commonly used for
quiet fan mode where C

stepwise: Add ceiling type

Add a stepwise ceiling type, this is used as a
upper clipping curve to limit the max output based
on a temperature sensor. This is commonly used for
quiet fan mode where CPU throttling is allowed to
preserve a max fan noise.

Change-Id: I181d5913c92e5498a34e6d3f67cf99b67471479c
Signed-off-by: James Feist <james.feist@linux.intel.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 ...

performance: fixup missing const reference in zone

Zone::getSensor is passed directly to the Sensor Manager getSensor which
takes the parameter by reference. Make it use an explicit const
reference

performance: fixup missing const reference in zone

Zone::getSensor is passed directly to the Sensor Manager getSensor which
takes the parameter by reference. Make it use an explicit const
reference at both layers.

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

show more ...

add .clang-format

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

test: pid: zone

Add unit-tests for the PID zone module.
Add zone_mock.

Tested: Ran on quanta-q71l board and it behaved as expected.

Change-Id: I51185b2d2daacea6ffb687e8f38c4fe2b2a1bed3
Signed-off-

test: pid: zone

Add unit-tests for the PID zone module.
Add zone_mock.

Tested: Ran on quanta-q71l board and it behaved as expected.

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

show more ...