kernel/linux.git/drivers/thermal/gov_step_wise.c, branch linux-7.1.y

thermal: gov_step_wise: Allow cooling level to be reduced earlier

2025-09-04T19:28:01+00:00

The current behavior of the Step-wise thermal governor is to increase the cooling level one step at a time after trip point threshold passing by thermal zone temperature until the temperature stops to rise. Then, nothing is done until the temperature decreases below the (possibly updated) trip point threshold, at which point the cooling level is reduced straight to the applicable minimum. While this generally works, it is not in agreement with the throttling logic description comment in step_wise_manage() any more after some relatively recent changes, and in the case of passive cooling, it may lead to undesirable performance oscillations between high and low levels. For this reason, modify the governor's cooling device state selection function, get_target_state(), to reduce cooling by one level even if the temperature is still above the thermal zone threshold, but the temperature has started to fall down. However, ensure that the cooling level will remain above the applicable minimum in that case to pull the zone temperature further down, possibly until it falls below the trip threshold (which may now be equal to the low temperature of the trip). Doing so should help higher performance to be restored earlier in some cases which is desirable especially for passive trip points with relatively high hysteresis values. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/1947735.tdWV9SEqCh@rafael.j.wysocki [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki

thermal: gov_step_wise: Clarify cooling logic description comment

2025-09-04T19:28:01+00:00

The cooling logic description comment next to the get_target_state() definition is slightly ambiguous in what it means by "lower cooling state", so clarify that by replacing the ambuguous phrase with "the minimum applicable cooling state". No functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/4690596.LvFx2qVVIh@rafael.j.wysocki

thermal: gov_step_wise: Clean up local variable initialization

2025-09-04T19:28:01+00:00

Make the initialization of local variable throttle in thermal_zone_trip_update() more straightforward. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Link: https://patch.msgid.link/6203592.lOV4Wx5bFT@rafael.j.wysocki

thermal: core: Add and use cooling device guard

2024-10-24T12:48:23+00:00

Add and use a special guard for cooling devices. This allows quite a few error code paths to be simplified among other things and brings in code size reduction for a good measure. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5837621.DvuYhMxLoT@rjwysocki.net Reviewed-by: Lukasz Luba

thermal: core: Move lists of thermal instances to trip descriptors

2024-10-22T10:08:03+00:00

In almost all places where a thermal zone's list of thermal instances is walked, there is a check to match a specific trip point and it is walked in vain whenever there are no cooling devices associated with the given trip. To address this, store the lists of thermal instances in trip point descriptors instead of storing them in thermal zones and adjust all code using those lists accordingly. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/5522726.Sb9uPGUboI@rjwysocki.net Reviewed-by: Lukasz Luba

thermal: gov_step_wise: Go straight to instance->lower when mitigation is over

2024-06-25T12:37:05+00:00

Commit b6846826982b ("thermal: gov_step_wise: Restore passive polling management") attempted to fix a Step-Wise thermal governor issue introduced by commit 042a3d80f118 ("thermal: core: Move passive polling management to the core"), which caused the governor to leave cooling devices in high states, by partially reverting that commit. However, this turns out to be insufficient on some systems due to interactions between the governor code restored by commit b6846826982b and the passive polling management in the thermal core. For this reason, revert commit b6846826982b and make the governor set the target cooling device state to the "lower" one as soon as the zone temperature falls below the threshold of the trip point corresponding to the given thermal instance, which means that thermal mitigation is not necessary any more. Before this change the "lower" cooling device state would be reached in steps through the passive polling mechanism which was questionable for three reasons: (1) cooling device were kept in high states when that was not necessary (and it could adversely impact performance), (2) it only worked for thermal zones with nonzero passive_delay_jiffies value, and (3) passive polling belongs to the core and should not be hijacked by governors for their internal purposes. Fixes: b6846826982b ("thermal: gov_step_wise: Restore passive polling management") Closes: https://lore.kernel.org/linux-pm/6759ce9f-281d-4fcd-bb4c-b784a1cc5f6e@oldschoolsolutions.biz Reported-by: Jens Glathe Tested-by: Jens Glathe Link: https://patch.msgid.link/12464461.O9o76ZdvQC@rjwysocki.net Signed-off-by: Rafael J. Wysocki Tested-by: Steev Klimaszewski Tested-by: Johan Hovold

thermal: gov_step_wise: Restore passive polling management

2024-06-11T19:00:44+00:00

Consider a thermal zone with one passive trip point, a cooling device with 3 states (0, 1, 2) bound to it, passive polling enabled (nonzero passive_delay_jiffies) and no regular polling (polling_delay_jiffies equal to 0) that is managed by the Step-Wise governor. Suppose that the initial state of the cooling device is 0 and the zone temperature is below the trip point to start with. When the trip point is crossed, tz->passive is incremented by the thermal core and the governor's .manage() callback is invoked. It sets 'throttle' to 'true' for the trip in question and get_target_state() returns 1 for the instance corresponding to the cooling device (say that 'upper' and 'lower' are set to 2 and 0 for it, respectively), so its state changes to 1. Passive polling is still active for the zone, so next time the temperature is updated, the governor's .manage() callback will be invoked again. If the temperature is still rising, it will change the state of the cooling device to 2. Now suppose that next time the zone temperature is updated, it falls below the trip point, so tz->passive is decremented for the zone (say it becomes 0 then) and the governor's .manage() callbacks runs. It finds that the temperature trend for the zone is 'falling' and 'throttle' will be set to 'false' for the trip in question, so the cooling device's state will be changed to 1. However, because tz->polling is 0 for the zone, the governor's .manage() callback may not be invoked again for a long time and the cooling device's state will not be reset back to 0. This can happen because commit 042a3d80f118 ("thermal: core: Move passive polling management to the core") removed passive polling management from the Step-Wise governor. Before that change, thermal_zone_trip_update() would bump up tz->passive when changing the target state for a thermal instance from "no target" to a specific value and it would drop tz->passive when changing it back to "no target" which would cause passive polling to be active for the zone until the governor has reset the states of all cooling devices. In particular, in the example above tz->passive would be incremented when changing the state of the cooling device from 0 to 1 and then it would be still nonzero when the state of the cooling device was changed from 2 to 1. To prevent this problem from occurring, restore the passive polling management in the Step-Wise governor by partially reverting the commit in question and update the comment in the restored code to explain its role more clearly. Fixes: 042a3d80f118 ("thermal: core: Move passive polling management to the core") Closes: https://lore.kernel.org/linux-pm/ZmVfcEOxmjUHZTSX@hovoldconsulting.com Reported-by: Johan Hovold Tested-by: Johan Hovold Signed-off-by: Rafael J. Wysocki

thermal: core: Move passive polling management to the core

2024-04-30T19:16:13+00:00

Passive polling is enabled by setting the 'passive' field in struct thermal_zone_device to a positive value so long as the 'passive_delay_jiffies' field is greater than zero. It causes the thermal core to actively check the thermal zone temperature periodically which in theory should be done after crossing a passive trip point on the way up in order to allow governors to react more rapidly to temperature changes and adjust mitigation more precisely. However, the 'passive' field in struct thermal_zone_device is currently managed by governors which is quite problematic. First of all, only two governors, Step-Wise and Power Allocator, update that field at all, so the other governors do not benefit from passive polling, although in principle they should. Moreover, if the zone governor is changed from, say, Step-Wise to Fair-Share after 'passive' has been incremented by the former, it is not going to be reset back to zero by the latter even if the zone temperature falls down below all passive trip points. For this reason, make handle_thermal_trip() increment 'passive' to enable passive polling for the given thermal zone whenever a passive trip point is crossed on the way up and decrement it whenever a passive trip point is crossed on the way down. Also remove the 'passive' field updates from governors and additionally clear it in thermal_zone_device_init() to prevent passive polling from being enabled after a system resume just beacuse it was enabled before suspending the system. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba

thermal: gov_step_wise: Clean up thermal_zone_trip_update()

2024-04-24T08:14:58+00:00

Do some assorted cleanups in thermal_zone_trip_update(): * Compute the trend value upfront. * Move old_target definition to the block where it is used. * Adjust white space around diagnostic messages and locking. * Use suitable field formatting in a message to avoid an explicit cast to int. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba

thermal: gov_step_wise: Use trip thresholds instead of trip temperatures

2024-04-24T08:14:33+00:00

In principle, the Step-Wise governor should take trip hysteresis into account. After all, once a trip has been crossed on the way up, mitigation is still needed until it is crossed on the way down. For this reason, make it use trip thresholds that are computed by the core when trips are crossed, so as to apply mitigations in the hysteresis rages of trips that were crossed on the way up, but have not been crossed on the way down yet. Signed-off-by: Rafael J. Wysocki Reviewed-by: Lukasz Luba Acked-by: Daniel Lezcano