Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: 2021-02-18 10:50:54
Also in:
linux-pm, lkml
On 17-02-21, 00:24, Ionela Voinescu wrote:
quoted
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c index 1e47dfd465f8..47fca7376c93 100644 --- a/arch/arm64/kernel/topology.c +++ b/arch/arm64/kernel/topology.c@@ -240,7 +240,6 @@ static struct scale_freq_data amu_sfd = { static void amu_fie_setup(const struct cpumask *cpus) { - bool invariant; int cpu; /* We are already set since the last insmod of cpufreq driver */@@ -257,25 +256,10 @@ static void amu_fie_setup(const struct cpumask *cpus) cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus); - invariant = topology_scale_freq_invariant(); - - /* We aren't fully invariant yet */ - if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) - return; -You still need these checks, otherwise you could end up with only part of the CPUs setting a scale factor, when only part of the CPUs support AMUs and there is no cpufreq support for FIE.
Another look at it and here goes another reason (hope I don't have another in-code comment somewhere else to kill this one) :) We don't need to care for the reason you gave (which is a valid reason otherwise), as we are talking specifically about amu_fie_setup() here and it gets called from cpufreq policy-notifier. i.e. we won't support AMUs without cpufreq being there in the first place and the same goes for cppc-driver. Does that sound reasonable ? -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel