[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8239b35e-8f51-e36c-96c6-4e5d986eebf9@arm.com>
Date: Tue, 16 Nov 2021 08:30:25 +0000
From: Lukasz Luba <lukasz.luba@....com>
To: Thara Gopinath <thara.gopinath@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org, steev@...i.org,
sudeep.holla@....com, will@...nel.org, catalin.marinas@....com,
linux@...linux.org.uk, gregkh@...uxfoundation.org,
rafael@...nel.org, viresh.kumar@...aro.org, amitk@...nel.org,
daniel.lezcano@...aro.org, amit.kachhap@...il.com,
bjorn.andersson@...aro.org, agross@...nel.org
Subject: Re: [PATCH v4 4/5] cpufreq: qcom-cpufreq-hw: Use new thermal pressure
update function
On 11/15/21 8: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.
>
> Yes, although cpuinfo.max_freq does not reflect the boost frequency
> unless boost is enabled atleast once. I have sent a patch to fix this.
> But I agree that using cpuinfo.max_freq has issues you have mentioned in
> this patch if boost is enabled once.
>
> So, for this patch
>
> Reviewed-by: Thara Gopinath <thara.gopinath@...aro.org>
Thank you for the review!
>
> Warm Regards
> Thara (She/Her/Hers)
Powered by blists - more mailing lists