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