| Message ID | 20240117110443.2060704-1-quic_sibis@quicinc.com |
|---|---|
| Headers | show |
| Series | cpufreq: scmi: Add boost frequency support | expand |
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.
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.
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?
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
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
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(-)