mbox series

[0/3] cpufreq: scmi: Add boost frequency support

Message ID 20240117110443.2060704-1-quic_sibis@quicinc.com
Headers
Series cpufreq: scmi: Add boost frequency support |

Message

Sibi Sankar Jan. 17, 2024, 11:04 a.m. UTC 
  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

 drivers/cpufreq/scmi-cpufreq.c   | 20 +++++++++++++++++++-
 drivers/firmware/arm_scmi/perf.c | 11 ++++++++++-
 drivers/opp/core.c               |  1 +
 include/linux/pm_opp.h           |  1 +
 4 files changed, 31 insertions(+), 2 deletions(-)

Comments

Viresh Kumar Jan. 23, 2024, 6:08 a.m. UTC | #1 
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.
Cristian Marussi Jan. 23, 2024, 8:49 a.m. UTC | #2 
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/

@Sudeep, I am going to start review on this series and the related one
these next few days.

Thanks,
Cristian
Sudeep Holla Jan. 23, 2024, 10:15 a.m. UTC | #3 
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.
Dietmar Eggemann Jan. 31, 2024, 3:07 p.m. UTC | #4 
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?
Sudeep Holla Jan. 31, 2024, 4:12 p.m. UTC | #5 
On Wed, Jan 31, 2024 at 04:07:48PM +0100, Dietmar Eggemann wrote:

[...]

>
> root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
> 1
> 0
> 0

OK I admit, I wasn't aware of this per policy boost flag.
It must be enabled by default if it has any effect. Otherwise
it breaks the existing behaviour on all the SCMI based platforms.
Sibi Sankar Feb. 13, 2024, 8:35 a.m. UTC | #6 
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

> 
>
Dietmar Eggemann Feb. 15, 2024, 2:57 p.m. UTC | #7 
On 13/02/2024 08:35, Sibi Sankar wrote:
> 
> 
> 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:

[...]

>> 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.

I see.

What about the issue with the settings of the global and the per-policy
'boost' file?

On my Juno-r0 the initial boost values are:

(1) Initial setting:

root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
1
0
0

Should they not all be 1 ?


(2) Disabling system-wide boost

root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost

Here I see 'cpufreq_pressure > 0' for all CPUs.


(3) Enabling system-wide boost

root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost

And here 'cpufreq_pressure == 0' for all CPUs.


(4) Disabling boost for policy0.

root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost

root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
1
0
1

Here nothing happened. But I was expecting to see 'cpufreq_pressure > 0'
for CPUs of policy0:

root@juno:/sys/devices/system/cpu/cpufreq# cat policy0/affected_cpus
0 3 4 5
Sibi Sankar Feb. 27, 2024, 6:44 p.m. UTC | #8 
On 2/15/24 20:27, Dietmar Eggemann wrote:
> On 13/02/2024 08:35, Sibi Sankar wrote:
>>
>>
>> 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:
> 
> [...]
> 

[...]

>>> 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.
> 
> I see.
> 
> What about the issue with the settings of the global and the per-policy
> 'boost' file?
> 
> On my Juno-r0 the initial boost values are:
> 
> (1) Initial setting:
> 
> root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
> 1
> 0
> 0
> 
> Should they not all be 1 ?
> 
> 
> (2) Disabling system-wide boost
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > boost
> 
> Here I see 'cpufreq_pressure > 0' for all CPUs.
> 
> 
> (3) Enabling system-wide boost
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 1 > boost
> 
> And here 'cpufreq_pressure == 0' for all CPUs.
> 
> 
> (4) Disabling boost for policy0.
> 
> root@juno:/sys/devices/system/cpu/cpufreq# echo 0 > policy0/boost
> 
> root@juno:/sys/devices/system/cpu/cpufreq# cat boost policy*/boost
> 1
> 0
> 1
> 
> Here nothing happened. But I was expecting to see 'cpufreq_pressure > 0'
> for CPUs of policy0:
> 

https://patchwork.kernel.org/project/linux-arm-msm/cover/20240227165309.620422-1-quic_sibis@quicinc.com/

Finally got some time to fix this, I've posted out the fix and re-spun
the series as well. This should fix the default values of per-policy
boost flags as well.

-Sibi

> root@juno:/sys/devices/system/cpu/cpufreq# cat policy0/affected_cpus
> 0 3 4 5