From 93d0c1ab23281fda96490f23cd6f2a1966fdc030 Mon Sep 17 00:00:00 2001 From: Sumit Gupta Date: Wed, 12 Aug 2020 01:13:17 +0530 Subject: [PATCH 1/4] cpufreq: replace cpu_logical_map() with read_cpuid_mpir() Commit eaecca9e7710 ("arm64: Fix __cpu_logical_map undefined issue") fixes the issue with building tegra194 cpufreq driver as module. But the fix might cause problem while supporting physical CPU hotplug[1]. This patch fixes the original problem by avoiding use of cpu_logical_map(). Instead calling read_cpuid_mpidr() to get MPIDR on target CPU. [1] https://lore.kernel.org/linux-arm-kernel/20200724131059.GB6521@bogus/ Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver") Reviewed-by: Sudeep Holla Signed-off-by: Sumit Gupta Acked-by: Viresh Kumar [ rjw: Subject & changelog edits ] Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/tegra194-cpufreq.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/tegra194-cpufreq.c b/drivers/cpufreq/tegra194-cpufreq.c index bae527e507e0..e1d931c457a7 100644 --- a/drivers/cpufreq/tegra194-cpufreq.c +++ b/drivers/cpufreq/tegra194-cpufreq.c @@ -56,9 +56,11 @@ struct read_counters_work { static struct workqueue_struct *read_counters_wq; -static enum cluster get_cpu_cluster(u8 cpu) +static void get_cpu_cluster(void *cluster) { - return MPIDR_AFFINITY_LEVEL(cpu_logical_map(cpu), 1); + u64 mpidr = read_cpuid_mpidr() & MPIDR_HWID_BITMASK; + + *((uint32_t *)cluster) = MPIDR_AFFINITY_LEVEL(mpidr, 1); } /* @@ -186,8 +188,10 @@ static unsigned int tegra194_get_speed(u32 cpu) static int tegra194_cpufreq_init(struct cpufreq_policy *policy) { struct tegra194_cpufreq_data *data = cpufreq_get_driver_data(); - int cl = get_cpu_cluster(policy->cpu); u32 cpu; + u32 cl; + + smp_call_function_single(policy->cpu, get_cpu_cluster, &cl, true); if (cl >= data->num_clusters) return -EINVAL; From 1c502821992d505747ee222bd358fee9cd836d18 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sun, 23 Aug 2020 16:04:11 -0700 Subject: [PATCH 2/4] Documentation: fix pm/intel_pstate build warning and wording Fix documentation build warning and sentence wording: Documentation/admin-guide/pm/intel_pstate.rst:568: WARNING: Unexpected indentation. Fixes: f473bf398bf1 ("cpufreq: intel_pstate: Allow raw energy performance preference value") Signed-off-by: Randy Dunlap Cc: Srinivas Pandruvada Cc: Rafael J. Wysocki Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/intel_pstate.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index 7adef969ffee..cdd1a9a7f9a2 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -564,8 +564,8 @@ Energy-Performance Preference (EPP) knob (if supported) or its Energy-Performance Bias (EPB) knob. It is also possible to write a positive integer value between 0 to 255, if the EPP feature is present. If the EPP feature is not present, writing integer value to this attribute is not -supported. In this case, user can use - "/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface. +supported. In this case, user can use the +"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface. [Note that tasks may by migrated from one CPU to another by the scheduler's load-balancing algorithm and if different energy vs performance hints are From 681fe68448ef370f1d7213cab38013ab8e9d8ff0 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Thu, 27 Aug 2020 10:54:15 +0530 Subject: [PATCH 3/4] cpufreq: No need to verify cpufreq_driver in show_scaling_cur_freq() "cpufreq_driver" is guaranteed to be valid here, no need to check it here. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki --- drivers/cpufreq/cpufreq.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 02ab56b2a0d8..47aa90f9a7c2 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -703,8 +703,7 @@ static ssize_t show_scaling_cur_freq(struct cpufreq_policy *policy, char *buf) freq = arch_freq_get_on_cpu(policy->cpu); if (freq) ret = sprintf(buf, "%u\n", freq); - else if (cpufreq_driver && cpufreq_driver->setpolicy && - cpufreq_driver->get) + else if (cpufreq_driver->setpolicy && cpufreq_driver->get) ret = sprintf(buf, "%u\n", cpufreq_driver->get(policy->cpu)); else ret = sprintf(buf, "%u\n", policy->cur); From 30b8e6b22fd0f7a56911e69c681e92532e72e3b6 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Thu, 27 Aug 2020 10:54:16 +0530 Subject: [PATCH 4/4] cpufreq: Use WARN_ON_ONCE() for invalid relation The relation can't be invalid here, so if it turns out to be invalid, just WARN_ON_ONCE() and return 0. Signed-off-by: Viresh Kumar [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki --- include/linux/cpufreq.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 8f141d4c859c..a911e5d06845 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -956,8 +956,8 @@ static inline int cpufreq_frequency_table_target(struct cpufreq_policy *policy, case CPUFREQ_RELATION_C: return cpufreq_table_find_index_c(policy, target_freq); default: - pr_err("%s: Invalid relation: %d\n", __func__, relation); - return -EINVAL; + WARN_ON_ONCE(1); + return 0; } }