On 19/10/2020 20:42, Thara Gopinath wrote: > On Wed, 16 Sep 2020 at 23:22, Thara Gopinath <thara.gopinath@xxxxxxxxxx> wrote: >> >> Thermal framework today supports monitoring for rising temperatures and >> subsequently initiating cooling action in case of a thermal trip point >> being crossed. There are scenarios where a SoC need warming mitigating >> action to be activated if the temperature falls below a cetain permissible >> limit. Since warming action can be considered mirror opposite of cooling >> action, most of the thermal framework can be re-used to achieve this. The >> key assumption in this patch series is that a device can act either as a >> warming device or a cooling device and not as both. >> >> In order to support warming three extensions are needed in the thermal >> framework. >> >> 1. Indication that a trip point is being monitored for falling temperature >> and not rising temperature. We discussed two different ways to achieve this >> during LPC. First option is to introduce a new trip type to indicate that a >> trip is a cold trip(THERMAL_TRIP_COLD). The second option is to introduce a >> new property for trip point that will indicate whether a trip point is >> being monitored for rising temperature or falling temperature. The patch >> series(patches 1-4) chooses the second approach since it allows trip points >> of any type to be monitored for rising or falling temperature.Also this was >> the preferred approach when discussed during LPC. The approach that >> introduces a new cold trip type was posted on the list earlier as a RFC and >> can be found at [1]. >> >> 2. Extend the exisitng governors to handle monitoring of falling >> temperature. The patch series(patches 5 & 6) extends the step wise governor >> to monitor the falling temperature.Other governors return doing nothing if >> the trip point they are being called for is being monitored for falling >> temperature. The governors' mitigate function is called "throttle" in the >> thermal framework and with this patch series it is a misnomer as the >> function is called for both throttling and warming up. Ideally >> "throttle" should be renamed to "mitigate" to improve readability of code. >> The renaming is not part of this series. >> >> 3. Finally, the cooling device framework itself can be reused for a warming >> device. As stated before a device can act either as a warming device or a >> cooling device and not as both. With this the cooling state in the >> framework can be considered as mitigating state with 0 as the state with no >> thermal mitigation and higher the number higher the thermal mitigation. >> Again what affects the code readability and comprehension is the term >> "cooling" which is a misnomer here. Ideally the term "cooling" should be >> renamed to "mitigating" and hence thermal_cooling_device will become >> thermal_mitgating_device. The renaming is not part of the patch series as >> even though the renaming is a simple search-replace, it will change a lot >> of files. The patch series(patches 7 & 8) instead introduces a minimal set >> of _warming_device_ apis to register and unregister warming devices which >> internally is identical to the _cooling_device_ counterpart. > > Gentle ping for review.. Pong, review before the end of this week. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
