Messages in this thread | | | Date | Fri, 31 Jul 2015 08:48:41 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH] thermal/cpu_cooling: remove local cooling state variable |
| |
Thanks.
I will try to add more layman terms here to map cooling state with frequencies. So, the cooling state 0 maps to the highest frequency the cpufreq table supports, and the highest cooling state n maps to the lowest frequency. Right ?
On 30-07-15, 13:21, Radivoje Jovanovic wrote: > In this case both userspace thermal solution and cpu_cooling are > changing policy->max and the userspace solution will let governor or HW > (depends on architecture) decide the clipped-freq. Now let us say that > cpu_cooling has 4 available states 0-3
Lets say: 0 == 1.2 GHz 1 == 1.1 GHz 2 == 1 GHz 3 == 800 MHz
> and let us say that cpu_cooling > has set the state 1 as the last state.
i.e. cpu_cooling says "don't go over 1.1 GHz"..
> Now userspace component comes in > and changes the state of the system that matches cpu_cooling state 0.
So, policy->max reaches 1.2 GHz and that is not in sync with cpu_cooling. Right ?
> cpu_cooling is unaware of this change and does not change the local > cur_state.
That's where I think you one of us might be incorrect. At this point when policy->max is changed to 1.2 GHz, a notifier will get issued to cpu_cooling, which will bring policy->max again to 1.1 GHz and so things will be back in control.
> Now the temperature changes and cpu_cooling should change > the system state to 1 (userspace component malfunctioned and is not > picking up this change) but since the cur_state is already at 1 > cpu_cooling will not do anything since it believes it is in the correct > state. Hope this explains it better
-- viresh
| |