From 7a451b380eb47300db9008e0aa90b6a2698b14c4 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 14 May 2021 17:40:22 +0200 Subject: [PATCH] 5.11-stable patches added patches: acpi-pm-add-acpi-id-of-alder-lake-fan.patch cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch --- ...cpi-pm-add-acpi-id-of-alder-lake-fan.patch | 32 +++++ ...-hwp-if-enabled-by-platform-firmware.patch | 64 ++++++++++ ...halt-polling-at-kvm-max_halt_poll_ns.patch | 37 ++++++ ...-parent-child_count-for-force_resume.patch | 110 ++++++++++++++++++ queue-5.11/series | 4 + 5 files changed, 247 insertions(+) create mode 100644 queue-5.11/acpi-pm-add-acpi-id-of-alder-lake-fan.patch create mode 100644 queue-5.11/cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch create mode 100644 queue-5.11/kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch create mode 100644 queue-5.11/pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch diff --git a/queue-5.11/acpi-pm-add-acpi-id-of-alder-lake-fan.patch b/queue-5.11/acpi-pm-add-acpi-id-of-alder-lake-fan.patch new file mode 100644 index 00000000000..81fd05ea3bc --- /dev/null +++ b/queue-5.11/acpi-pm-add-acpi-id-of-alder-lake-fan.patch @@ -0,0 +1,32 @@ +From 2404b8747019184002823dba7d2f0ecf89d802b7 Mon Sep 17 00:00:00 2001 +From: Sumeet Pawnikar +Date: Tue, 11 May 2021 23:31:42 +0530 +Subject: ACPI: PM: Add ACPI ID of Alder Lake Fan + +From: Sumeet Pawnikar + +commit 2404b8747019184002823dba7d2f0ecf89d802b7 upstream. + +Add a new unique fan ACPI device ID for Alder Lake to +support it in acpi_dev_pm_attach() function. + +Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake") +Signed-off-by: Sumeet Pawnikar +Acked-by: Zhang Rui +Cc: 5.10+ # 5.10+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/device_pm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/device_pm.c ++++ b/drivers/acpi/device_pm.c +@@ -1314,6 +1314,7 @@ int acpi_dev_pm_attach(struct device *de + {"PNP0C0B", }, /* Generic ACPI fan */ + {"INT3404", }, /* Fan */ + {"INTC1044", }, /* Fan for Tiger Lake generation */ ++ {"INTC1048", }, /* Fan for Alder Lake generation */ + {} + }; + struct acpi_device *adev = ACPI_COMPANION(dev); diff --git a/queue-5.11/cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch b/queue-5.11/cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch new file mode 100644 index 00000000000..6efc6b313aa --- /dev/null +++ b/queue-5.11/cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch @@ -0,0 +1,64 @@ +From e5af36b2adb858e982d78d41d7363d05d951a19a Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Wed, 21 Apr 2021 19:40:56 +0200 +Subject: cpufreq: intel_pstate: Use HWP if enabled by platform firmware + +From: Rafael J. Wysocki + +commit e5af36b2adb858e982d78d41d7363d05d951a19a upstream. + +It turns out that there are systems where HWP is enabled during +initialization by the platform firmware (BIOS), but HWP EPP support +is not advertised. + +After commit 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP +if EPP is not supported") intel_pstate refuses to use HWP on those +systems, but the fallback PERF_CTL interface does not work on them +either because of enabled HWP, and once enabled, HWP cannot be +disabled. Consequently, the users of those systems cannot control +CPU performance scaling. + +Address this issue by making intel_pstate use HWP unconditionally if +it is enabled already when the driver starts. + +Fixes: 7aa1031223bc ("cpufreq: intel_pstate: Avoid enabling HWP if EPP is not supported") +Reported-by: Srinivas Pandruvada +Tested-by: Srinivas Pandruvada +Signed-off-by: Rafael J. Wysocki +Cc: 5.9+ # 5.9+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/intel_pstate.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/drivers/cpufreq/intel_pstate.c ++++ b/drivers/cpufreq/intel_pstate.c +@@ -3053,6 +3053,14 @@ static const struct x86_cpu_id hwp_suppo + {} + }; + ++static bool intel_pstate_hwp_is_enabled(void) ++{ ++ u64 value; ++ ++ rdmsrl(MSR_PM_ENABLE, value); ++ return !!(value & 0x1); ++} ++ + static int __init intel_pstate_init(void) + { + const struct x86_cpu_id *id; +@@ -3071,8 +3079,12 @@ static int __init intel_pstate_init(void + * Avoid enabling HWP for processors without EPP support, + * because that means incomplete HWP implementation which is a + * corner case and supporting it is generally problematic. ++ * ++ * If HWP is enabled already, though, there is no choice but to ++ * deal with it. + */ +- if (!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) { ++ if ((!no_hwp && boot_cpu_has(X86_FEATURE_HWP_EPP)) || ++ intel_pstate_hwp_is_enabled()) { + hwp_active++; + hwp_mode_bdw = id->driver_data; + intel_pstate.attr = hwp_cpufreq_attrs; diff --git a/queue-5.11/kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch b/queue-5.11/kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch new file mode 100644 index 00000000000..da17a833f03 --- /dev/null +++ b/queue-5.11/kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch @@ -0,0 +1,37 @@ +From 258785ef08b323bddd844b4926a32c2b2045a1b0 Mon Sep 17 00:00:00 2001 +From: David Matlack +Date: Thu, 6 May 2021 15:24:43 +0000 +Subject: kvm: Cap halt polling at kvm->max_halt_poll_ns + +From: David Matlack + +commit 258785ef08b323bddd844b4926a32c2b2045a1b0 upstream. + +When growing halt-polling, there is no check that the poll time exceeds +the per-VM limit. It's possible for vcpu->halt_poll_ns to grow past +kvm->max_halt_poll_ns and stay there until a halt which takes longer +than kvm->halt_poll_ns. + +Signed-off-by: David Matlack +Signed-off-by: Venkatesh Srinivas +Message-Id: <20210506152442.4010298-1-venkateshs@chromium.org> +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + virt/kvm/kvm_main.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2734,8 +2734,8 @@ static void grow_halt_poll_ns(struct kvm + if (val < grow_start) + val = grow_start; + +- if (val > halt_poll_ns) +- val = halt_poll_ns; ++ if (val > vcpu->kvm->max_halt_poll_ns) ++ val = vcpu->kvm->max_halt_poll_ns; + + vcpu->halt_poll_ns = val; + out: diff --git a/queue-5.11/pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch b/queue-5.11/pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch new file mode 100644 index 00000000000..a6075c7c5c8 --- /dev/null +++ b/queue-5.11/pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch @@ -0,0 +1,110 @@ +From c745253e2a691a40c66790defe85c104a887e14a Mon Sep 17 00:00:00 2001 +From: Tony Lindgren +Date: Wed, 5 May 2021 14:09:15 +0300 +Subject: PM: runtime: Fix unpaired parent child_count for force_resume + +From: Tony Lindgren + +commit c745253e2a691a40c66790defe85c104a887e14a upstream. + +As pm_runtime_need_not_resume() relies also on usage_count, it can return +a different value in pm_runtime_force_suspend() compared to when called in +pm_runtime_force_resume(). Different return values can happen if anything +calls PM runtime functions in between, and causes the parent child_count +to increase on every resume. + +So far I've seen the issue only for omapdrm that does complicated things +with PM runtime calls during system suspend for legacy reasons: + +omap_atomic_commit_tail() for omapdrm.0 + dispc_runtime_get() + wakes up 58000000.dss as it's the dispc parent + dispc_runtime_resume() + rpm_resume() increases parent child_count + dispc_runtime_put() won't idle, PM runtime suspend blocked +pm_runtime_force_suspend() for 58000000.dss, !pm_runtime_need_not_resume() + __update_runtime_status() +system suspended +pm_runtime_force_resume() for 58000000.dss, pm_runtime_need_not_resume() + pm_runtime_enable() only called because of pm_runtime_need_not_resume() +omap_atomic_commit_tail() for omapdrm.0 + dispc_runtime_get() + wakes up 58000000.dss as it's the dispc parent + dispc_runtime_resume() + rpm_resume() increases parent child_count + dispc_runtime_put() won't idle, PM runtime suspend blocked +... +rpm_suspend for 58000000.dss but parent child_count is now unbalanced + +Let's fix the issue by adding a flag for needs_force_resume and use it in +pm_runtime_force_resume() instead of pm_runtime_need_not_resume(). + +Additionally omapdrm system suspend could be simplified later on to avoid +lots of unnecessary PM runtime calls and the complexity it adds. The +driver can just use internal functions that are shared between the PM +runtime and system suspend related functions. + +Fixes: 4918e1f87c5f ("PM / runtime: Rework pm_runtime_force_suspend/resume()") +Signed-off-by: Tony Lindgren +Reviewed-by: Ulf Hansson +Tested-by: Tomi Valkeinen +Cc: 4.16+ # 4.16+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/runtime.c | 10 +++++++--- + include/linux/pm.h | 1 + + 2 files changed, 8 insertions(+), 3 deletions(-) + +--- a/drivers/base/power/runtime.c ++++ b/drivers/base/power/runtime.c +@@ -1637,6 +1637,7 @@ void pm_runtime_init(struct device *dev) + dev->power.request_pending = false; + dev->power.request = RPM_REQ_NONE; + dev->power.deferred_resume = false; ++ dev->power.needs_force_resume = 0; + INIT_WORK(&dev->power.work, pm_runtime_work); + + dev->power.timer_expires = 0; +@@ -1804,10 +1805,12 @@ int pm_runtime_force_suspend(struct devi + * its parent, but set its status to RPM_SUSPENDED anyway in case this + * function will be called again for it in the meantime. + */ +- if (pm_runtime_need_not_resume(dev)) ++ if (pm_runtime_need_not_resume(dev)) { + pm_runtime_set_suspended(dev); +- else ++ } else { + __update_runtime_status(dev, RPM_SUSPENDED); ++ dev->power.needs_force_resume = 1; ++ } + + return 0; + +@@ -1834,7 +1837,7 @@ int pm_runtime_force_resume(struct devic + int (*callback)(struct device *); + int ret = 0; + +- if (!pm_runtime_status_suspended(dev) || pm_runtime_need_not_resume(dev)) ++ if (!pm_runtime_status_suspended(dev) || !dev->power.needs_force_resume) + goto out; + + /* +@@ -1853,6 +1856,7 @@ int pm_runtime_force_resume(struct devic + + pm_runtime_mark_last_busy(dev); + out: ++ dev->power.needs_force_resume = 0; + pm_runtime_enable(dev); + return ret; + } +--- a/include/linux/pm.h ++++ b/include/linux/pm.h +@@ -600,6 +600,7 @@ struct dev_pm_info { + unsigned int idle_notification:1; + unsigned int request_pending:1; + unsigned int deferred_resume:1; ++ unsigned int needs_force_resume:1; + unsigned int runtime_auto:1; + bool ignore_children:1; + unsigned int no_callbacks:1; diff --git a/queue-5.11/series b/queue-5.11/series index 18296d920c1..16c2458c250 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -5,3 +5,7 @@ tpm-tpm_tis-reserve-locality-in-tpm_tis_resume.patch kvm-svm-make-sure-ghcb-is-mapped-before-updating.patch kvm-x86-mmu-remove-the-defunct-update_pte-paging-hook.patch kvm-vmx-invoke-nmi-non-ist-entry-instead-of-ist-entry.patch +acpi-pm-add-acpi-id-of-alder-lake-fan.patch +pm-runtime-fix-unpaired-parent-child_count-for-force_resume.patch +cpufreq-intel_pstate-use-hwp-if-enabled-by-platform-firmware.patch +kvm-cap-halt-polling-at-kvm-max_halt_poll_ns.patch -- 2.47.3