Received-SPF: pass (google.com: domain of linux-kernel+bounces-63129-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <01b3d0ed-3fd3-86c6-7b0f-48d34a5d9ba8@quicinc.com>
Date: Tue, 13 Feb 2024 14:05:35 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 0/3] cpufreq: scmi: Add boost frequency support
Content-Language: en-US
To: Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Sudeep Holla
	<sudeep.holla@arm.com>,
        Viresh Kumar <viresh.kumar@linaro.org>
CC: <cristian.marussi@arm.com>, <rafael@kernel.org>,
        <morten.rasmussen@arm.com>, <lukasz.luba@arm.com>, <sboyd@kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <linux-pm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <quic_mdtipton@quicinc.com>,
        <linux-arm-msm@vger.kernel.org>, <nm@ti.com>
References: <20240117110443.2060704-1-quic_sibis@quicinc.com>
 <20240123060827.a3vszziftj6pszt3@vireshk-i7> <Za-RtBrSxI-j4Jdx@bogus>
 <e968092a-dc2b-4351-9489-acf874bbc7b6@arm.com>
From: Sibi Sankar <quic_sibis@quicinc.com>
In-Reply-To: <e968092a-dc2b-4351-9489-acf874bbc7b6@arm.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit


On 1/31/24 20:37, Dietmar Eggemann wrote:
> On 23/01/2024 11:15, Sudeep Holla wrote:
>> On Tue, Jan 23, 2024 at 11:38:27AM +0530, Viresh Kumar wrote:
>>> On 17-01-24, 16:34, Sibi Sankar wrote:
>>>> This series adds provision to mark dynamic opps as boost capable and adds
>>>> boost frequency support to the scmi cpufreq driver.
>>>>
>>>> Depends on:
>>>> HW pressure v4: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240109164655.626085-1-vincent.guittot@linaro.org/
>>>> scmi notification v2: https://patchwork.kernel.org/project/linux-arm-msm/cover/20240117104116.2055349-1-quic_sibis@quicinc.com/
>>>>
>>>> Sibi Sankar (3):
>>>>    OPP: Extend dev_pm_opp_data with turbo support
>>>>    firmware: arm_scmi: Add support for marking certain frequencies as
>>>>      boost
>>>>    cpufreq: scmi: Enable boost support
>>>
>>> Sudeep, please lemme know if you are okay with the changes. Will apply
>>> them.
>>
>> I was planning to look at it once Lukasz/Dietmar confirm that this concept
>> doesn't change anything fundamental in the way EAS related changes work
>> today. I know I suggested the change as that seem to be right way to do
>> but I haven't analysed if this has any negative impact on the existing
>> features as this change will impact all the existing platform with OPPs
>> above sustained performance/frequency advertised from the SCMI platform
>> firmware.
> 
> I was mostly concerned about the settings for the CPU frequency
> invariance implementation in [drivers/base/arch_topology.c]:
> 
> #define arch_scale_freq_capacity topology_get_freq_scale
> 
> But per_cpu(capacity_freq_ref, cpu) is still set to
> 'policy->cpuinfo.max_freq' in init_cpu_capacity_callback()
> which stays the same.
> 
> With some extra debugging I get the following on Juno-r0 [L b b L L L]:
> 
> root@juno:~# dmesg -w | grep -i "freq\|boost\|noti\|OPP\|cap"
> 
> [    1.768414] arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
> [    1.793084] [1][LITTLE_CPU]:: Registered OPP[0] 450000000
> [    1.798624] [1][LITTLE_CPU]:: Registered OPP[1] 575000000
> [    1.804131] [1][LITTLE_CPU]:: Registered OPP[2] 700000000
> [    1.809552] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=775000000
> [    1.816971] [1][LITTLE_CPU]:: Registered OPP[3] 775000000
> [    1.822392] scmi_dvfs_device_opps_add() sustained_freq=700000000 freq=850000000
> [    1.829800] [1][LITTLE_CPU]:: Registered OPP[4] 850000000
> [    1.835268] enabled boost: 0
> [    1.838173] init_cpu_capacity_callback() cpu=0 max_freq=850000
> [    1.844032] init_cpu_capacity_callback() cpu=3 max_freq=850000
> [    1.849886] init_cpu_capacity_callback() cpu=4 max_freq=850000
> [    1.855743] init_cpu_capacity_callback() cpu=5 max_freq=850000
> [    1.866324] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0
> [    1.872178] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0
> [    1.878026] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0
> [    1.883874] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0
> [    1.890633] [0][BIG_CPU]:: Registered OPP[0] 450000000
> [    1.895892] [0][BIG_CPU]:: Registered OPP[1] 625000000
> [    1.901129] [0][BIG_CPU]:: Registered OPP[2] 800000000
> [    1.906286] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=950000000
> [    1.906381] [0][BIG_CPU]:: Registered OPP[3] 950000000
> [    1.917377] scmi_dvfs_device_opps_add() sustained_freq=800000000 freq=1100000000
> [    1.917468] [0][BIG_CPU]:: Registered OPP[4] 1100000000
> [    1.939237] enabled boost: 0
> [    1.942134] init_cpu_capacity_callback() cpu=1 max_freq=1100000
> [    1.948078] init_cpu_capacity_callback() cpu=2 max_freq=1100000
> [    1.959003] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0
> [    1.964853] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0
> 
> root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
> 1
> 0
> 0
> 
> root@juno:/sys/devices/system/cpu/cpufreq# cat policy*/scaling_available_frequencies policy*/scaling_boost_frequencies
> 450000 575000 700000
> 450000 625000 800000
> 775000 850000
> 950000 1100000
> 
> If I disable system-wide boost I see the correct influence on
> 'cpufreq_pressure':
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost
> 
> [  439.466682] cpufreq_update_pressure() cpu=1 cpufreq_pressure=280
> [  439.472797] cpufreq_update_pressure() cpu=2 cpufreq_pressure=280
> [  439.478889] cpufreq_update_pressure() cpu=0 cpufreq_pressure=79
> [  439.484852] cpufreq_update_pressure() cpu=3 cpufreq_pressure=79
> [  439.490843] cpufreq_update_pressure() cpu=4 cpufreq_pressure=79
> [  439.499621] cpufreq_update_pressure() cpu=5 cpufreq_pressure=79
> 
> reflecting the max frequency change from '1100000 to 800000' on CPU1,2
> and from '850000 to 700000' on CPU0,3-5.
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost
> 
> [ 2722.693113] cpufreq_update_pressure() cpu=1 cpufreq_pressure=0
> [ 2722.699041] cpufreq_update_pressure() cpu=2 cpufreq_pressure=0
> [ 2722.704962] cpufreq_update_pressure() cpu=0 cpufreq_pressure=0
> [ 2722.710842] cpufreq_update_pressure() cpu=3 cpufreq_pressure=0
> [ 2722.719644] cpufreq_update_pressure() cpu=4 cpufreq_pressure=0
> [ 2722.728224] cpufreq_update_pressure() cpu=5 cpufreq_pressure=0
> 
> What doesn't work for me is to disable boost per policy:
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost
> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost
> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy1/boost
> 
> Here I don't see 'cpufreq_pressure' changes.
> 
> BTW, what's the use case you have in mind for this feature? Is it to cap
> high OPPs for CPUs in a certain CPUfreq policy?

Yeah, that's exactly the use case for X1E. Boost frequencies defined in
the SoC are achievable by only one CPU in a cluster i.e. either the
other CPUs in the same cluster should be in low power mode or offline.
So it's mostly for book keeping i.e. we wouldn't to intimate incorrectly
that the CPUs are running at max possible frequency when it's actually
running at a lower frequency.

-Sibi

> 
>