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

fix CI failed

- Refs about removing add_object_vtable:
https://gerrit.openbmc.org/c/openbmc/phosphor-hwmon/+/73009

- initial some struct data

Signed-off-by: Harvey Wu <Harvey.Wu@quantatw.com>
Chan

fix CI failed

- Refs about removing add_object_vtable:
https://gerrit.openbmc.org/c/openbmc/phosphor-hwmon/+/73009

- initial some struct data

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

show more ...

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda forma

clang-format: re-format for clang-18

clang-format-18 isn't compatible with the clang-format-17 output, so we
need to reformat the code with the latest version. The way clang-18
handles lambda formatting also changed, so we have made changes to the
organization default style format to better handle lambda formatting.

See I5e08687e696dd240402a2780158664b7113def0e for updated style.
See Iea0776aaa7edd483fa395e23de25ebf5a6288f71 for clang-18 enablement.

Change-Id: I0f105c3310e87172c65a09a8787a2db5a4041cc0
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

fancontroller: Add missing config.h

Include config.h to satisfy #ifdef used in those files.

Change-Id: I0f6a3aa750abdf7b7c263d05f0551ee481b98d51
Signed-off-by: Patrick Rudolph <patrick.rudolph@9ele

fancontroller: Add missing config.h

Include config.h to satisfy #ifdef used in those files.

Change-Id: I0f6a3aa750abdf7b7c263d05f0551ee481b98d51
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>

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

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer retur

build: use allowed over enabled

Meson feature options are typically in a tri-state of enabled, disabled,
or auto. The enabled and disabled functions on an option (from
`get_option`) no longer return true for auto features. Instead, the
expectation is to use `allowed()` which is true for both enabled and auto.

Switch all uses of `enabled` to `allowed`.

Change-Id: I816b3334e4bb65384a49bc34af6ae5fe092c923e
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

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

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-17 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: Ic0bb299201cf8abb024b7d4aca465d50cbc8b585
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

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

zone: Add debug interface to zone dbus path

- Add xyz.openbmc_project.Debug.Pid.Zone interface to fanctrl/zoneX dbus
to record the PID config name which is driving this zone.

TEST:
```
busctl int

zone: Add debug interface to zone dbus path

- Add xyz.openbmc_project.Debug.Pid.Zone interface to fanctrl/zoneX dbus
to record the PID config name which is driving this zone.

TEST:
```
busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0 xyz.openbmc_project.Debug.Pid.Zone
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
.Leader property s "CPU0_PID" emits-change
```

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

show more ...

fix compile error when enable meson test option

- Fix compile error:
[-Werror=sign-compare]

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

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

Allow disabling PID loops at runtime

<design concept>
Add the map of object enable interface to pid loops
in the zone then we can disable/enable each pid loop
process in a zone by dbus command.

[no

Allow disabling PID loops at runtime

<design concept>
Add the map of object enable interface to pid loops
in the zone then we can disable/enable each pid loop
process in a zone by dbus command.

[note]
Enable = true : enable process (default)
Enable = false : disable process

Tested:
In this case: we set Enable = false to disable
pidloop:Zone_Temp_0, and see how it affects
the zone final pwm, when pidloop: Zone_Temp_0
in zone 0 is disabled.

then even we are trying to heat up the temperature
of a sensor: Temp_0 in pidloop: Zone_Temp_0, this
set point of the pidloop will not be taken into the
calculation for the final set point of the whole zone.

```
<service object>
root@openbmc:/tmp# busctl tree xyz.openbmc_project.State.FanCtrl
`-/xyz
`-/xyz/openbmc_project
`-/xyz/openbmc_project/settings
`-/xyz/openbmc_project/settings/fanctrl
|-/xyz/openbmc_project/settings/fanctrl/zone0
| |-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp
| |-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
| `-/xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_1

====Enable process for pidloop:Zone_Temp_0 with p-switch temperature sensor:Temp_0 at runtime====
root@openbmc:~# busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
xyz.openbmc_project.Object.Enable interface - - -
.Enabled property b true emits-change writable

====Disable process for pidloop:Zone_Temp_0 with p-switch temperature sensor: Temp_0====
root@openbmc:~# busctl set-property xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0 xyz.openbmc_project.Object.Enable Enabled b false
root@openbmc:~# busctl introspect xyz.openbmc_project.State.FanCtrl /xyz/openbmc_project/settings/fanctrl/zone0/Zone_Temp_0
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
xyz.openbmc_project.Object.Enable interface - - -
.Enabled property b false emits-change writable
```

when Disable the process of the pidloop: Zone_Temp_0,
the requester switches from Zone_Temp_0 to the others,
when you enable the pidloop: Zone_Temp_0, the setpoint
of Zone_Temp_0 will be take into consideration again

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

show more ...

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest

clang-format: copy latest and re-format

clang-format-16 has some backwards incompatible changes that require
additional settings for best compatibility and re-running the formatter.
Copy the latest .clang-format from the docs repository and reformat the
repository.

Change-Id: Icbc50d46e84ee7ef756705e2b19741439a325074
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>

show more ...

meson: Remove autotools files and ignore patches

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

Fix interval calculation bug and D-Bus init

The new timing parameters were not settable from the D-Bus code path,
only from the old static JSON code path. Also, the divison would not
occur, causing

Fix interval calculation bug and D-Bus init

The new timing parameters were not settable from the D-Bus code path,
only from the old static JSON code path. Also, the divison would not
occur, causing the variable to remain at 1000 by default, not 10,
causing the thermal intervals to run 100 times slower than intended!

I fixed the algorithm used to calculate when the thermal intervals
should be inserted amongst the fan intervals. Now, the division is
not necessary, and any value should work, so long as the thermal
interval is greater than or equal to the fan interval.

I also fixed a subtle bug regarding the timer scheduling. It was
reinitializing the timer expiration time from "now" each interval,
instead of cleanly incrementing from the original expiration. This
caused the timer to run slower than intended, as the execution time
of each interval would not be subtracted out from the remaining time
that needs to be waited for, as it should have been.

Tested: Default values, for timing parameters, now work as intended

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

show more ...

Allow derivativeCoeff and DCoefficient optional

To avoid breaking existing configurations in the field, treat the
new "derivativeCoeff" parameter as optional, not mandatory.

This affects both the o

Allow derivativeCoeff and DCoefficient optional

To avoid breaking existing configurations in the field, treat the
new "derivativeCoeff" parameter as optional, not mandatory.

This affects both the old JSON parser, and the new D-Bus
entity-manager parser (it's called "DCoefficient" there).

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

show more ...

Add new PID Class types "power" and "powersum"

Implements this feature:
https://github.com/openbmc/phosphor-pid-control/issues/24

In addition to the existing "temp" and "margin" classes, adding
new

Add new PID Class types "power" and "powersum"

Implements this feature:
https://github.com/openbmc/phosphor-pid-control/issues/24

In addition to the existing "temp" and "margin" classes, adding
new "power" and "powersum" Class types.

The "power" class is the same as "temp", but expects D-Bus power
sensors, instead of D-Bus temperature sensors.

The "powersum" class is the same as "power", but sums together all of
the given inputs, instead of finding the maximum.

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

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

Adding new feature of core PID loop logging

This differs from the normal logging,
as this focuses on the core of the PID loop computations.

All variables within the core pid/ec/pid.cpp pid()
functi

Adding new feature of core PID loop logging

This differs from the normal logging,
as this focuses on the core of the PID loop computations.

All variables within the core pid/ec/pid.cpp pid()
function are now logged, so math can be debugged.

Output is throttled to only log a new line
when it changes, or when 60 seconds have elapsed.

Creates 2 files for each PID loop,
one showing coefficients that were configured for it,
and one showing the variables changing over time.

Enable by --corelogging command line option,
or by creating /etc/thermal.d/corelogging file.

Tested:
Log files appear as expected, when enabled.
No changes noticed, when this feature is disabled.

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

show more ...

Fix Meson build problem when building tests

Somehow, the top of tree broke, and Jenkins now complains when trying
to upload a new patch. I am not sure why Jenkins did not catch this
earlier. Regardl

Fix Meson build problem when building tests

Somehow, the top of tree broke, and Jenkins now complains when trying
to upload a new patch. I am not sure why Jenkins did not catch this
earlier. Regardless, this should fix it.

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

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