1# Control.ThermalMode dbus interface with Supported and Current properties 2 3Author: 4 Matthew Barth !msbarth 5 6Other contributors: 7 None 8 9Created: 10 2019-02-06 11 12## Problem Description 13An issue was discovered where the exhaust heat from the system GPUs causes 14overtemp warnings on optical cables on certain system configurations. The 15issue can be resolved by altering the fan control application's floor table, 16effectively raising the floor when these optical cables exist but an interface 17is needed to do so. Since the issue revolves around the optical cables 18themselves, where no current mechanism exists to detect the presence of the 19optical cables plugged into a card downwind from the GPUs' exhaust, 20an end-user must be presented with an ability to enable this raised floor 21speed table. 22 23## Background and References 24The witherspoon system supports pci cards that could have optical cables 25plugged in place of copper cables. These optical cables can report overtemp 26warnings to the OS when high GPU utilization workloads exist. When this occurs 27with low enough CPU utilization, the fans could be kept at a given floor speed 28that sufficiently cools the components within the chassis, but not the optical 29cables with the slow moving hot exhaust. 30 31Without an available exhaust temp sensor, there's no direct way to determine 32the exhaust temp and include that within the fan control algorithm. A similar 33issue exists on other system where mathematical calculations are done based on 34the overall power dissipation. 35 36Mathematical calculations to logically estimate exit air temps: 37https://github.com/openbmc/dbus-sensors/blob/master/src/ExitAirTempSensor.cpp 38 39## Requirements 40Create the ability for an end-user to enable the use of a thermal control mode 41other than the default. In this use-case, the mode is specific to an 42undetectable configuration that alters the fan floor speeds unrelated to 43standardized profile/modes such "Acoustic" and "Performance". Once the end-user 44selects a documented mode for the platform, the thermal control application 45alters its control algorithm according to the defined mode, which is 46implementation specific to that instance of the application on that platform. 47 48## Proposed Design 49Create a Control.ThermalMode dbus interface containing a supported list of 50available thermal control modes along with what current mode is in use. 51Initially the current mode would be set to "Default" and the implementation 52of the interface would populate the supported list of modes. 53 54As one implementation, phosphor-fan-presence/control would be updated to extend 55this dbus interface object which would fill in the list of supported modes 56from its fan control configuration for the platform. Once the fan control 57application starts, the interface would be added on the zone object and 58available to be queried for supported modes or update the current mode. 59An end-user may set the current mode to any of those supported modes and the 60current mode would be persisted each time it is updated. This is to ensure 61each time the fan control application zone objects are started, the last set 62control mode is used. 63 64## Alternatives Considered 65Mathematical calculation to create a virtual exhaust temp sensor value based 66on overall power dissipation. However, in the witherspoon situation, using 67this technique would not be reliable in adjusting the floor speeds for only 68configurations using optical cables. This would instead present the possibility 69of raising floor speeds for configurations where its unnecessary. 70 71## Impacts 72The thermal control application used must be configured to provide what thermal 73control modes are supported/available on the interface as well as perform the 74associated control changes when a mode is set. 75 76## Testing 77Trigger the use of an alternative fan floor table based on the thermal control 78mode selected on a witherspoon system. 79