--- /dev/null
+From 2404b8747019184002823dba7d2f0ecf89d802b7 Mon Sep 17 00:00:00 2001
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+Date: Tue, 11 May 2021 23:31:42 +0530
+Subject: ACPI: PM: Add ACPI ID of Alder Lake Fan
+
+From: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
+
+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 <sumeet.r.pawnikar@intel.com>
+Acked-by: Zhang Rui <rui.zhang@intel.com>
+Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From e5af36b2adb858e982d78d41d7363d05d951a19a Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Wed, 21 Apr 2021 19:40:56 +0200
+Subject: cpufreq: intel_pstate: Use HWP if enabled by platform firmware
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+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 <srinivas.pandruvada@linux.intel.com>
+Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Cc: 5.9+ <stable@vger.kernel.org> # 5.9+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 258785ef08b323bddd844b4926a32c2b2045a1b0 Mon Sep 17 00:00:00 2001
+From: David Matlack <dmatlack@google.com>
+Date: Thu, 6 May 2021 15:24:43 +0000
+Subject: kvm: Cap halt polling at kvm->max_halt_poll_ns
+
+From: David Matlack <dmatlack@google.com>
+
+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 <dmatlack@google.com>
+Signed-off-by: Venkatesh Srinivas <venkateshs@chromium.org>
+Message-Id: <20210506152442.4010298-1-venkateshs@chromium.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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:
--- /dev/null
+From c745253e2a691a40c66790defe85c104a887e14a Mon Sep 17 00:00:00 2001
+From: Tony Lindgren <tony@atomide.com>
+Date: Wed, 5 May 2021 14:09:15 +0300
+Subject: PM: runtime: Fix unpaired parent child_count for force_resume
+
+From: Tony Lindgren <tony@atomide.com>
+
+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 <tony@atomide.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Cc: 4.16+ <stable@vger.kernel.org> # 4.16+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
