mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sibi Sankar <quic_sibis@quicinc.com>
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>
Subject: Re: [PATCH 0/3] cpufreq: scmi: Add boost frequency support
Date: Tue, 13 Feb 2024 14:05:35 +0530	[thread overview]
Message-ID: <01b3d0ed-3fd3-86c6-7b0f-48d34a5d9ba8@quicinc.com> (raw)
In-Reply-To: <e968092a-dc2b-4351-9489-acf874bbc7b6@arm.com>



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

> 
> 

  parent reply	other threads:[~2024-02-13  8:35 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-17 11:04 Sibi Sankar
2024-01-17 11:04 ` [PATCH 1/3] OPP: Extend dev_pm_opp_data with turbo support Sibi Sankar
2024-02-26 16:29   ` Lukasz Luba
2024-01-17 11:04 ` [PATCH 2/3] firmware: arm_scmi: Add support for marking certain frequencies as boost Sibi Sankar
2024-01-31 11:25   ` Sudeep Holla
2024-02-13  8:30     ` Sibi Sankar
2024-01-31 14:29   ` Pierre Gondois
2024-01-31 16:08     ` Sudeep Holla
2024-02-13  8:03       ` Sibi Sankar
2024-01-17 11:04 ` [PATCH 3/3] cpufreq: scmi: Enable boost support Sibi Sankar
2024-01-23  6:08 ` [PATCH 0/3] cpufreq: scmi: Add boost frequency support Viresh Kumar
2024-01-23  8:49   ` Cristian Marussi
2024-01-23 10:15   ` Sudeep Holla
2024-01-31 15:07     ` Dietmar Eggemann
2024-01-31 16:12       ` Sudeep Holla
2024-02-13  8:35       ` Sibi Sankar [this message]
2024-02-15 14:57         ` Dietmar Eggemann
2024-02-27 18:44           ` Sibi Sankar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01b3d0ed-3fd3-86c6-7b0f-48d34a5d9ba8@quicinc.com \
    --to=quic_sibis@quicinc.com \
    --cc=cristian.marussi@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=morten.rasmussen@arm.com \
    --cc=nm@ti.com \
    --cc=quic_mdtipton@quicinc.com \
    --cc=rafael@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®