summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorMario Limonciello <mario.limonciello@amd.com>2023-01-20 13:15:18 -0600
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2023-02-09 11:28:13 +0100
commit72e5a83b7c8401856cc3732150af24e43726717a (patch)
treea85b8f98a03f3f6a9d66dac7c4b3f656a3637a3d /net
parent37e9784331f27ddaf3e24aba8c9a163ab7f74ac7 (diff)
downloadlinux-stable-72e5a83b7c8401856cc3732150af24e43726717a.tar.gz
linux-stable-72e5a83b7c8401856cc3732150af24e43726717a.tar.bz2
linux-stable-72e5a83b7c8401856cc3732150af24e43726717a.zip
platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/CZN
[ Upstream commit 8e60615e8932167057b363c11a7835da7f007106 ] By default when the system is configured for low power idle in the FADT the keyboard is set up as a wake source. This matches the behavior that Windows uses for Modern Standby as well. It has been reported that a variety of AMD based designs there are spurious wakeups are happening where two IRQ sources are active. For example: ``` PM: Triggering wakeup from IRQ 9 PM: Triggering wakeup from IRQ 1 ``` In these designs IRQ 9 is the ACPI SCI and IRQ 1 is the keyboard. One way to trigger this problem is to suspend the laptop and then unplug the AC adapter. The SOC will be in a hardware sleep state and plugging in the AC adapter returns control to the kernel's s2idle loop. Normally if just IRQ 9 was active the s2idle loop would advance any EC transactions and no other IRQ being active would cause the s2idle loop to put the SOC back into hardware sleep state. When this bug occurred IRQ 1 is also active even if no keyboard activity occurred. This causes the s2idle loop to break and the system to wake. This is a platform firmware bug triggering IRQ1 without keyboard activity. This occurs in Windows as well, but Windows will enter "SW DRIPS" and then with no activity enters back into "HW DRIPS" (hardware sleep state). This issue affects Renoir, Lucienne, Cezanne, and Barcelo platforms. It does not happen on newer systems such as Mendocino or Rembrandt. It's been fixed in newer platform firmware. To avoid triggering the bug on older systems check the SMU F/W version and adjust the policy at suspend time for s2idle wakeup from keyboard on these systems. A lot of thought and experimentation has been given around the timing of disabling IRQ1, and to make it work the "suspend" PM callback is restored. Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reported-by: Xaver Hugl <xaver.hugl@gmail.com> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2115 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1951 Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20230120191519.15926-1-mario.limonciello@amd.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions