From 93d0c1ab23281fda96490f23cd6f2a1966fdc030 Mon Sep 17 00:00:00 2001 From: Sumit Gupta Date: Wed, 12 Aug 2020 01:13:17 +0530 Subject: [PATCH 1/5] 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/5] 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 e3eb6e8fba65094328b8dca635d00de74ba75b45 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 24 Aug 2020 19:35:31 +0200 Subject: [PATCH 3/5] PM: sleep: core: Fix the handling of pending runtime resume requests It has been reported that system-wide suspend may be aborted in the absence of any wakeup events due to unforseen interactions of it with the runtume PM framework. One failing scenario is when there are multiple devices sharing an ACPI power resource and runtime-resume needs to be carried out for one of them during system-wide suspend (for example, because it needs to be reconfigured before the whole system goes to sleep). In that case, the runtime-resume of that device involves turning the ACPI power resource "on" which in turn causes runtime-resume requests to be queued up for all of the other devices sharing it. Those requests go to the runtime PM workqueue which is frozen during system-wide suspend, so they are not actually taken care of until the resume of the whole system, but the pm_runtime_barrier() call in __device_suspend() sees them and triggers system wakeup events for them which then cause the system-wide suspend to be aborted if wakeup source objects are in active use. Of course, the logic that leads to triggering those wakeup events is questionable in the first place, because clearly there are cases in which a pending runtime resume request for a device is not connected to any real wakeup events in any way (like the one above). Moreover, it is racy, because the device may be resuming already by the time the pm_runtime_barrier() runs and so if the driver doesn't take care of signaling the wakeup event as appropriate, it will be lost. However, if the driver does take care of that, the extra pm_wakeup_event() call in the core is redundant. Accordingly, drop the conditional pm_wakeup_event() call fron __device_suspend() and make the latter call pm_runtime_barrier() alone. Also modify the comment next to that call to reflect the new code and extend it to mention the need to avoid unwanted interactions between runtime PM and system-wide device suspend callbacks. Fixes: 1e2ef05bb8cf8 ("PM: Limit race conditions between runtime PM and system sleep (v2)") Signed-off-by: Rafael J. Wysocki Acked-by: Alan Stern Reported-by: Utkarsh H Patel Tested-by: Utkarsh H Patel Tested-by: Pengfei Xu Cc: All applicable --- drivers/base/power/main.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index 9dd85bea4026..205a06752ca9 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -1606,13 +1606,17 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async) } /* - * If a device configured to wake up the system from sleep states - * has been suspended at run time and there's a resume request pending - * for it, this is equivalent to the device signaling wakeup, so the - * system suspend operation should be aborted. + * Wait for possible runtime PM transitions of the device in progress + * to complete and if there's a runtime resume request pending for it, + * resume it before proceeding with invoking the system-wide suspend + * callbacks for it. + * + * If the system-wide suspend callbacks below change the configuration + * of the device, they must disable runtime PM for it or otherwise + * ensure that its runtime-resume callbacks will not be confused by that + * change in case they are invoked going forward. */ - if (pm_runtime_barrier(dev) && device_may_wakeup(dev)) - pm_wakeup_event(dev, 0); + pm_runtime_barrier(dev); if (pm_wakeup_pending()) { dev->power.direct_complete = false; From 681fe68448ef370f1d7213cab38013ab8e9d8ff0 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Thu, 27 Aug 2020 10:54:15 +0530 Subject: [PATCH 4/5] 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 5/5] 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; } }