Messages in this thread | | | Subject | Re: [PATCH v4 4/5] cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function | From | Lukasz Luba <> | Date | Tue, 16 Nov 2021 08:28:53 +0000 |
| |
Hi Thara,
On 11/15/21 11:39 PM, Thara Gopinath wrote: > > > On 11/15/21 3:57 PM, Thara Gopinath wrote: >> >> >> On 11/9/21 2:57 PM, Lukasz Luba wrote: >>> Thermal pressure provides a new API, which allows to use CPU frequency >>> as an argument. That removes the need of local conversion to capacity. >>> Use this new API and remove old local conversion code. >>> >>> The new arch_update_thermal_pressure() also accepts boost frequencies, >>> which solves issue in the driver code with wrong reduced capacity >>> calculation. The reduced capacity was calculated wrongly due to >>> 'policy->cpuinfo.max_freq' used as a divider. The value present there >>> was >>> actually the boost frequency. Thus, even a normal maximum frequency >>> value >>> which corresponds to max CPU capacity (arch_scale_cpu_capacity(cpu_id)) >>> is not able to remove the capping. > > Also I failed to mention that, currently freq_factor is initialized as > cpuinfo.max_freq / 1000 which means again all the issues you mentioned > below can be hit, if some cpufreq driver decides to set boost at init. > I have sent a patch earlier today to fix this.
Yes, you are right.
> > https://lore.kernel.org/linux-arm-msm/20211115201010.68567-1-thara.gopinath@linaro.org/T/#u > >
Looking at the change, it makes sense. I'll try to respond to that patch.
Thank you for looking into this issue.
Regards, Lukasz
| |