mbox series

[RFC,0/8] Introduce warming in thermal framework

Message ID 20200917032226.820371-1-thara.gopinath@linaro.org (mailing list archive)
Headers show
Series Introduce warming in thermal framework | expand

Message

Thara Gopinath Sept. 17, 2020, 3:22 a.m. UTC
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.

1. https://lkml.org/lkml/2020/7/10/639

Thara Gopinath (8):
  dt-bindings: thermal: Introduce monitor-falling parameter to thermal
    trip point binding
  thermal: Introduce new property monitor_type for trip point.
  thermal: thermal_of: Extend thermal dt driver to support
    bi-directional monitoring of a thermal trip point.
  thermal:core:Add genetlink notifications for monitoring falling
    temperature
  thermal: gov_step_wise: Extend thermal step-wise governor to monitor
    falling temperature.
  thermal: Modify thermal governors to do nothing for trip points being
    monitored for falling temperature
  thermal:core: Add is_warming_dev and supporting warming device api's
    to the cooling dev framework.
  soc:qcom:qcom_aoss: Change cooling_device_register to
    warming_device_register

 .../bindings/thermal/thermal-zones.yaml       |   7 ++
 drivers/soc/qcom/qcom_aoss.c                  |   6 +-
 drivers/thermal/gov_bang_bang.c               |  12 ++
 drivers/thermal/gov_fair_share.c              |  12 ++
 drivers/thermal/gov_power_allocator.c         |  12 ++
 drivers/thermal/gov_step_wise.c               |  62 +++++++---
 drivers/thermal/thermal_core.c                | 113 +++++++++++++++---
 drivers/thermal/thermal_core.h                |   2 +
 drivers/thermal/thermal_of.c                  |  22 ++++
 include/linux/thermal.h                       |   9 ++
 include/uapi/linux/thermal.h                  |   5 +
 11 files changed, 226 insertions(+), 36 deletions(-)

Comments

Thara Gopinath Oct. 19, 2020, 6:42 p.m. UTC | #1
On Wed, 16 Sep 2020 at 23:22, Thara Gopinath <thara.gopinath@linaro.org> 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..

>
> 1. https://lkml.org/lkml/2020/7/10/639
>
> Thara Gopinath (8):
>   dt-bindings: thermal: Introduce monitor-falling parameter to thermal
>     trip point binding
>   thermal: Introduce new property monitor_type for trip point.
>   thermal: thermal_of: Extend thermal dt driver to support
>     bi-directional monitoring of a thermal trip point.
>   thermal:core:Add genetlink notifications for monitoring falling
>     temperature
>   thermal: gov_step_wise: Extend thermal step-wise governor to monitor
>     falling temperature.
>   thermal: Modify thermal governors to do nothing for trip points being
>     monitored for falling temperature
>   thermal:core: Add is_warming_dev and supporting warming device api's
>     to the cooling dev framework.
>   soc:qcom:qcom_aoss: Change cooling_device_register to
>     warming_device_register
>
>  .../bindings/thermal/thermal-zones.yaml       |   7 ++
>  drivers/soc/qcom/qcom_aoss.c                  |   6 +-
>  drivers/thermal/gov_bang_bang.c               |  12 ++
>  drivers/thermal/gov_fair_share.c              |  12 ++
>  drivers/thermal/gov_power_allocator.c         |  12 ++
>  drivers/thermal/gov_step_wise.c               |  62 +++++++---
>  drivers/thermal/thermal_core.c                | 113 +++++++++++++++---
>  drivers/thermal/thermal_core.h                |   2 +
>  drivers/thermal/thermal_of.c                  |  22 ++++
>  include/linux/thermal.h                       |   9 ++
>  include/uapi/linux/thermal.h                  |   5 +
>  11 files changed, 226 insertions(+), 36 deletions(-)
>
> --
> 2.25.1
>
Daniel Lezcano Oct. 19, 2020, 7:22 p.m. UTC | #2
On 19/10/2020 20:42, Thara Gopinath wrote:
> On Wed, 16 Sep 2020 at 23:22, Thara Gopinath <thara.gopinath@linaro.org> 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.