From nobody Fri Dec 19 09:43:17 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADB882609EE; Thu, 1 May 2025 21:41:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746135719; cv=none; b=gaCLBgAmFqDG6LTt9cl1WMqma76RwBqyYhlrIOcl8zLvby9NOJa90Vv8CVFUhklz+O1krRerMc+OQMMj3OYFmJMlMktZQoPRZFI0qedXeiUYYwdYoUHb0WiownsSTMNVYDWauj7L06V3rOBBSqBY1Eli1pL2aFTvwo1MMUWinKg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1746135719; c=relaxed/simple; bh=B3PglZ+pvgJP2ISlJ2Sq8zygIlejDe4OGFJRYaY3r2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AgRf9B6i2NU1TOtOz08uWnMdUbBNeE6LjgNP87XK9MT60BVwKfcaP0QeYnatTnAIarJsyOtjvkwUpdIdwtFOpkzuh8jckOCDi4q274kR+bNOWjrfZdclKxLnVsmPDgEix9fGme4+zAv02uTpTPgQ4IuSTtbaD+muHlBOMS6Isow= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ID9NGssA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ID9NGssA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F22A0C4CEEE; Thu, 1 May 2025 21:41:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1746135718; bh=B3PglZ+pvgJP2ISlJ2Sq8zygIlejDe4OGFJRYaY3r2k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ID9NGssAgixdi0wHgYaadgF4ZtXzwiSsIueq5J7GL7GjFawnDhHl+Tj4PpZnlad7T YcNz6eeih1hO499nj3RoD4RP786ATdx+7wkpag3DgQmO4K1lX00nOcp/AI/Wybd49f TZlIlrAGjCxnXGdO4j7BxpwfoDr22ax/lgcEBWMBSMoEdfRCnlyaN3Od3Dxd9Io5GJ Vic/HhIwdJ+1bG6YYkE4ieuY6fwwV6iR2ZrLFO60XewaTnKsURMG8Irp1W81IOqgNU ZWD1kSG22WkRQ2mBpF6trBg2GPgr29IT5YR0TG2yZJExjaZo9XWr5D2dCYgrZdNR/R r1wu4W7RKJciQ== From: Mario Limonciello To: Borislav Petkov Cc: Jonathan Corbet , Mario Limonciello , Yazen Ghannam , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), "H . Peter Anvin" , Shyam Sundar S K , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), "Gautham R . Shenoy" Subject: [PATCH v6 1/2] Documentation: Add AMD Zen debugging document Date: Thu, 1 May 2025 16:41:46 -0500 Message-ID: <20250501214147.2488164-2-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250501214147.2488164-1-superm1@kernel.org> References: <20250501214147.2488164-1-superm1@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mario Limonciello Debugging issues on AMD hardware can be challenging for users without proper documentation and tools. Introduce a document that includes techniques for debugging s2idle issues. It will be expanded for debugging other issues later. Reviewed-by: Gautham R. Shenoy Signed-off-by: Mario Limonciello --- v5: * Add a section for BIOS argument parsing * Update URLS for amd-debug-tools to point at the about page instead of duplication of documentation. v4: * :: instead of ::: * Fix URL for hpd commit to upstreamed commit ID * Use suggested text * Add drm/amd bug tracker link * Move to arch/x86 directory instead v3: * Move debugging.rst to index.rst --- Documentation/arch/x86/amd-debugging.rst | 321 +++++++++++++++++++++++ Documentation/arch/x86/index.rst | 1 + Documentation/arch/x86/resume.svg | 4 + Documentation/arch/x86/suspend.svg | 4 + 4 files changed, 330 insertions(+) create mode 100644 Documentation/arch/x86/amd-debugging.rst create mode 100644 Documentation/arch/x86/resume.svg create mode 100644 Documentation/arch/x86/suspend.svg diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/= x86/amd-debugging.rst new file mode 100644 index 0000000000000..9bfc852606c51 --- /dev/null +++ b/Documentation/arch/x86/amd-debugging.rst @@ -0,0 +1,321 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Debugging AMD Zen systems ++++++++++++++++++++++++++ + +Introduction +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +This document describes techniques that are useful for debugging issues wi= th +AMD Zen systems. It is intended for use by developers and technical users +to help identify and resolve issues. + +S3 vs s2idle +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +On AMD systems, it's not possible to simultaneously support suspend-to-RAM= (S3) +and suspend-to-idle (s2idle). To confirm which mode your system supports = you +can look at ``cat /sys/power/mem_sleep``. If it shows ``s2idle [deep]`` t= hen +*S3* is supported. If it shows ``[s2idle]`` then *s2idle* is +supported. + +On systems that support *S3*, the firmware will be utilized to put all har= dware into +the appropriate low power state. + +On systems that support *s2idle*, the kernel will be responsible for trans= itioning devices +into the appropriate low power state. When all devices are in the appropri= ate low +power state, the hardware will transition into a hardware sleep state. + +After a suspend cycle you can tell how much time was spent in a hardware s= leep +state by looking at ``cat /sys/power/suspend_stats/last_hw_sleep``. + +This flowchart explains how the amd s2idle suspend flow works. + +.. kernel-figure:: suspend.svg + +This flowchart explains how the amd s2idle resume flow works. + +.. kernel-figure:: resume.svg + +s2idle debugging tool +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +As there are a lot of places that problems can occur, a debugging tool has= been +created at +`amd-debug-tools `_ +that can help test for common problems and offer suggestions. + +If you have an s2idle issue, it's best to start with this and follow instr= uctions +from its findings. If you continue to have an issue, raise a bug with the +report generated from this script to +`drm/amd gitlab `_. + +Spurious s2idle wakeups from an IRQ +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Spurious wakeups will generally have an IRQ set to ``/sys/power/pm_wakeup_= irq``. +This can be matched to ``/proc/interrupts`` to determine what device woke = the system. + +If this isn't enough to debug the problem, then the following sysfs files +can be set to add more verbosity to the wakeup process: :: + + # echo 1 | sudo tee /sys/power/pm_debug_messages + # echo 1 | sudo tee /sys/power/pm_print_times + +After making those changes, the kernel will display messages that can +be traced back to kernel s2idle loop code as well as display any active +GPIO sources while waking up. + +If the wakeup is caused by the ACPI SCI, additional ACPI debugging may be +needed. These commands can enable additional trace data: :: + + # echo enable | sudo tee /sys/module/acpi/parameters/trace_state + # echo 1 | sudo tee /sys/module/acpi/parameters/aml_debug_output + # echo 0x0800000f | sudo tee /sys/module/acpi/parameters/debug_level + # echo 0xffff0000 | sudo tee /sys/module/acpi/parameters/debug_layer + +Spurious s2idle wakeups from a GPIO +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +If a GPIO is active when waking up the system ideally you would look at the +schematic to determine what device it is associated with. If the schematic +is not available, another tactic is to look at the ACPI _EVT() entry +to determine what device is notified when that GPIO is active. + +For a hypothetical example, say that GPIO 59 woke up the system. You can +look at the SSDT to determine what device is notified when GPIO 59 is acti= ve. + +First convert the GPIO number into hex. :: + + $ python3 -c "print(hex(59))" + 0x3b + +Next determine which ACPI table has the ``_EVT`` entry. For example: :: + + $ sudo grep EVT /sys/firmware/acpi/tables/SSDT* + grep: /sys/firmware/acpi/tables/SSDT27: binary file matches + +Decode this table:: + + $ sudo cp /sys/firmware/acpi/tables/SSDT27 . + $ sudo iasl -d SSDT27 + +Then look at the table and find the matching entry for GPIO 0x3b. :: + + Case (0x3B) + { + M000 (0x393B) + M460 (" Notify (\\_SB.PCI0.GP17.XHC1, 0x02)\n", Zero, Zero, Zero,= Zero, Zero, Zero) + Notify (\_SB.PCI0.GP17.XHC1, 0x02) // Device Wake + } + +You can see in this case that the device ``\_SB.PCI0.GP17.XHC1`` is notifi= ed +when GPIO 59 is active. It's obvious this is an XHCI controller, but to go= a +step further you can figure out which XHCI controller it is by matching it= to +ACPI.:: + + $ grep "PCI0.GP17.XHC1" /sys/bus/acpi/devices/*/path + /sys/bus/acpi/devices/device:2d/path:\_SB_.PCI0.GP17.XHC1 + /sys/bus/acpi/devices/device:2e/path:\_SB_.PCI0.GP17.XHC1.RHUB + /sys/bus/acpi/devices/device:2f/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1 + /sys/bus/acpi/devices/device:30/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1.CAM0 + /sys/bus/acpi/devices/device:31/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT1.CAM1 + /sys/bus/acpi/devices/device:32/path:\_SB_.PCI0.GP17.XHC1.RHUB.PRT2 + /sys/bus/acpi/devices/LNXPOWER:0d/path:\_SB_.PCI0.GP17.XHC1.PWRS + +Here you can see it matches to ``device:2d``. Look at the ``physical_node`` +to determine what PCI device that actually is. :: + + $ ls -l /sys/bus/acpi/devices/device:2d/physical_node + lrwxrwxrwx 1 root root 0 Feb 12 13:22 /sys/bus/acpi/devices/device:2d/ph= ysical_node -> ../../../../../pci0000:00/0000:00:08.1/0000:c2:00.4 + +So there you have it: the PCI device associated with this GPIO wakeup was = ``0000:c2:00.4``. + +The ``amd_s2idle.py`` script will capture most of these artifacts for you. + +s2idle PM debug messages +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +During the s2idle flow on AMD systems, the ACPI LPS0 driver is responsible +to check all uPEP constraints. Failing uPEP constraints does not prevent +s0i3 entry. This means that if some constraints are not met, it is possib= le +the kernel may attempt to enter s2idle even if there are some known issues. + +To activate PM debugging, either specify ``pm_debug_messagess`` kernel +command-line option at boot or write to ``/sys/power/pm_debug_messages``. +Unmet constraints will be displayed in the kernel log and can be +viewed by logging tools that process kernel ring buffer like ``dmesg`` or +``journalctl``." + +If the system freezes on entry/exit before these messages are flushed, a +useful debugging tactic is to unbind the ``amd_pmc`` driver to prevent +notification to the platform to start s0i3 entry. This will stop the +system from freezing on entry or exit and let you view all the failed +constraints. :: + + cd /sys/bus/platform/drivers/amd_pmc + ls | grep AMD | sudo tee unbind + +After doing this, run the suspend cycle and look specifically for errors a= round: :: + + ACPI: LPI: Constraint not met; min power state:%s current power state:%s + +Historical examples of s2idle issues +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +To help understand the types of issues that can occur and how to debug the= m, +here are some historical examples of s2idle issues that have been resolved. + +Core offlining +-------------- +An end user had reported that taking a core offline would prevent the syst= em +from properly entering s0i3. This was debugged using internal AMD tools +to capture and display a stream of metrics from the hardware showing what = changed +when a core was offlined. It was determined that the hardware didn't get +notification the offline cores were in the deepest state, and so it preven= ted +CPU from going into the deepest state. The issue was debugged to a missing +command to put cores into C3 upon offline. + +`commit d6b88ce2eb9d2 ("ACPI: processor idle: Allow playing dead in C3 sta= te") `_ + +Corruption after resume +----------------------- +A big problem that occurred with Rembrandt was that there was graphical +corruption after resume. This happened because of a misalignment of PSP +and driver responsibility. The PSP will save and restore DMCUB, but the +driver assumed it needed to reset DMCUB on resume. +This actually was a misalignment for earlier silicon as well, but was not +observed. + +`commit 79d6b9351f086 ("drm/amd/display: Don't reinitialize DMCUB on s0ix = resume") `_ + +Back to Back suspends fail +-------------------------- +When using a wakeup source that triggers the IRQ to wakeup, a bug in the +pinctrl-amd driver may capture the wrong state of the IRQ and prevent the +system going back to sleep properly. + +`commit b8c824a869f22 ("pinctrl: amd: Don't save/restore interrupt status = and wake status bits") `_ + +Spurious timer based wakeup after 5 minutes +------------------------------------------- +The HPET was being used to program the wakeup source for the system, howev= er +this was causing a spurious wakeup after 5 minutes. The correct alarm to = use +was the ACPI alarm. + +`commit 3d762e21d5637 ("rtc: cmos: Use ACPI alarm for non-Intel x86 system= s too") `_ + +Disk disappears after resume +---------------------------- +After resuming from s2idle, the NVME disk would disappear. This was due t= o the +BIOS not specifying the _DSD StorageD3Enable property. This caused the NV= ME +driver not to put the disk into the expected state at suspend and to fail +on resume. + +`commit e79a10652bbd3 ("ACPI: x86: Force StorageD3Enable on more products"= ) `_ + +Spurious IRQ1 +------------- +A number of Renoir, Lucienne, Cezanne, & Barcelo platforms have a +platform firmware bug where IRQ1 is triggered during s0i3 resume. + +This was fixed in the platform firmware, but a number of systems didn't +receive any more platform firmware updates. + +`commit 8e60615e89321 ("platform/x86/amd: pmc: Disable IRQ1 wakeup for RN/= CZN") `_ + +Hardware timeout +---------------- +The hardware performs many actions besides accepting the values from +amd-pmc driver. As the communication path with the hardware is a mailbox, +it's possible that it might not respond quickly enough. +This issue manifested as a failure to suspend: :: + + PM: dpm_run_callback(): acpi_subsys_suspend_noirq+0x0/0x50 returns -110 + amd_pmc AMDI0005:00: PM: failed to suspend noirq: error -110 + +The timing problem was identified by comparing the values of the idle mask. + +`commit 3c3c8e88c8712 ("platform/x86: amd-pmc: Increase the response regis= ter timeout") `_ + +Failed to reach hardware sleep state with panel on +-------------------------------------------------- +On some Strix systems certain panels were observed to block the system from +entering a hardware sleep state if the internal panel was on during the se= quence. + +Even though the panel got turned off during suspend it exposed a timing pr= oblem +where an interrupt caused the display hardware to wake up and block low po= wer +state entry. + +`commit 40b8c14936bd2 ("drm/amd/display: Disable unneeded hpd interrupts d= uring dm_init") `_ + +Runtime power consumption issues +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D +Runtime power consumption is influenced by many factors, including but not +limited to the configuration of the PCIe Active State Power Management (AS= PM), +the display brightness, the EPP policy of the CPU, and the power management +of the devices. + +ASPM +---- +For the best runtime power consumption, ASPM should be programmed as inten= ded +by the BIOS from the hardware vendor. To accomplish this the Linux kernel +should be compiled with ``CONFIG_PCIEASPM_DEFAULT`` set to ``y`` and the +sysfs file ``/sys/module/pcie_aspm/parameters/policy`` should not be modif= ied. + +Most notably, if L1.2 is not configured properly for any devices, the SoC +will not be able to enter the deepest idle state. + +EPP Policy +---------- +The ``energy_performance_preference`` sysfs file can be used to set a bias +of efficiency or performance for a CPU. This has a direct relationship on +the battery life when more heavily biased towards performance. + + +BIOS debug messages +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Most OEM machines don't have a serial UART for outputting kernel or BIOS +debug messages. However BIOS debug messages are useful for understanding +both BIOS bugs and bugs with the Linux kernel drivers that call BIOS AML. + +As the BIOS on most OEM AMD systems are based off an AMD reference BIOS, +the infrastructure used for exporting debugging messages is often the same +as AMD reference BIOS. + +Manually Parsing +---------------- +There is generally an ACPI method ``\M460`` that different paths of the AML +will call to emit a message to the BIOS serial log. This method takes +7 arguments, with the first being a string and the rest being optional +integers:: + + Method (M460, 7, Serialized) + +Here is an example of a string that BIOS AML may call out using ``\M460``:: + + M460 (" OEM-ASL-PCIe Address (0x%X)._REG (%d %d) PCSA =3D %d\n", DADR,= Arg0, Arg1, PCSA, Zero, Zero) + +Normally when executed, the ``\M460`` method would populate the additional +arguments into the string. In order to get these messages from the Linux +kernel a hook has been added into ACPICA that can capture the *arguments* +sent to ``\M460`` and print them to the kernel ring buffer. +For example the following message could be emitted into kernel ring buffer= :: + + extrace-0174 ex_trace_args : " OEM-ASL-PCIe Address (0x%X)._RE= G (%d %d) PCSA =3D %d\n", ec106000, 2, 1, 1, 0, 0 + +In order to get these messages, you need to compile with ``CONFIG_ACPI_DEB= UG`` +and then turn on the following ACPICA tracing parameters. +This can be done either on the kernel command line or at runtime: + +* ``acpi.trace_method_name=3D\M460`` +* ``acpi.trace_state=3Dmethod`` + +NOTE: These can be very noisy at bootup. If you turn these parameters on +the kernel command, please also consider turning up ``CONFIG_LOG_BUF_SHIFT= `` +to a larger size such as 17 to avoid losing early boot messages. + +Tool assisted Parsing +--------------------- +As mentioned above, parsing by hand can be tedious, especially with a lot = of +messages. To help with this, a tool has been created at +`amd-debug-tools `_ +to help parse the messages. + diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/inde= x.rst index fb167e6bb9d52..cd9143d623872 100644 --- a/Documentation/arch/x86/index.rst +++ b/Documentation/arch/x86/index.rst @@ -25,6 +25,7 @@ x86-specific Documentation shstk iommu intel_txt + amd-debugging amd-memory-encryption amd_hsmp amd-hfi diff --git a/Documentation/arch/x86/resume.svg b/Documentation/arch/x86/res= ume.svg new file mode 100644 index 0000000000000..ad8839f762bfe --- /dev/null +++ b/Documentation/arch/x86/resume.svg @@ -0,0 +1,4 @@ + + + +<= g data-cell-id=3D"jeVlbFHk8Qahp5zcIn_D-10">
Wakeup event occurs
MP1 = hands off control to OS
OS Moves one core out of ACPI C3
=
MP0/MP1 boot process
<= g data-cell-id=3D"jeVlbFHk8Qahp5zcIn_D-13">
=
OS checks all wake sources
<= /div>
no
yes
<= image x=3D"303" y=3D"506" width=3D"18" height=3D"15.75" xlink:href=3D"data:= image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAAA/CAYAAABDyo4+AAAAAXNSR0IArs= 4c6QAACIdJREFUeF7tWXuMHHUd/3xnd++uFAQC6bUUMUAkJmIDOdvbZ11oqS1IgTaz2yttqY80V= atEYzRSFZpIExSDNJAWYgSDxe4OtEV5BUqz3D5m75rTEBrARgFTtekZLMfJ9fZ2dr7mt7d73Z3X= zt1Wc01m/tz9Pj/zfQ/BexwRIA8fZwQ8gFpEiAeQB1B7RcSLIC+CvAhqDwEvgtrDz6tBXgR5EdQ= eAl4EtYefV4O8CPIiqD0EZnMEybLsO36CbiDgKwBuBNBds/c0gPcBekUn/fGBrPI2AJ4OEpOyfZ= 8ncB+gLwfoCgAXNMgYZeCExFRg0lOd/rmZTObJcaMOCkXlFwFaZVJO9IiaTX3bjWHhaOI+Bu41C= Qd2FHLp+6wcC8XkL4CxB6DPtHKcgaIOumswlzrWilb8Hw4nF7PEvwZwrRv6Gs2/ANx9+QJOK4pS= qfNRMJK8k4h/ayHoqF72LR8Y+N1JJyU9y+ULO8YhQA4b6D4inVcWCopq+J1C0cQ3APwcwJxpOHC= KiDcWssoLTjzBSHINET9piBa3aiogPDQxdtE9Q0OPlwUTLVkqX+nT6TUAVxqkTAB8m5pTXnaSHg= 7LIZZI0HyimY5fQgVrVVUR6TL1hKLJTQDvmSY4df5RZtpczKf2W9kUiaz9rE6+VwBc5hYRC7oKM= 7YV82lhI0Sbp1AsuQvM24zEDDxRzKW/6pRmdukFYJuaSz/aBM7SdddD1wWY89pw4Kju11YNZPb/= 3RSZNn7MQNfbmiR98Uj/vuPVOag3IkclqkbBXIOw9yoSLxvsV96zUhKNrr+4gvJLAPU2/s/AcT8= q8Vzu2Xfrv/f0bAl0njfyFDMnLWSNEnB/qYv3DB1SRkTado7TVga2W6UKWdS2nnjfpR2a9hpAiw= zyTwH4scTSgXx+3wnxskUBf/+k7zI/V74Mpu9Z6WCmDcV8am8VIIc6UiGiDYVsap8VQPbA0tOd/= pN3ZTIZrc5nn4oYhiTdofbvKxh11OT/HsDFhv9M9TEclq+DRK8ycGnTyyJsL2bTO+2iKBxLbADj= IQB/YmaVWMr7fOU358/3DYtiPTVJh6KJbwJ4xCzI7OyU05HE/Uy4x8BTYeY1xbwiHJt6grHE94n= xgEUaP1DMpX9ok8Z26T/BwC3FXPpQwwuwBAjAIVQ4qarKv2eQatUaVH2i0bVXafBlCPhkq3SZpL= dOLwCmtxuPb+4qaR8rAH3JYKTJUaMTwUhyFRH/AYCv8T9i7Czk0yIFq49Diom/RaN4nQh7SZcO1= 1PNDWBTAMXjcX9J6/4NwOtNjExb1Xzqscbf7dKLgV3FXPruRlqn+qCDbxrIKUN2xvZG5R4J9KpF= mimd/uH1DWls22wsZI8C/CYIByVdf3F8/JJj9bZupG1aVkNReSVAzwHoaCbk5zv9c+XGSTNsnV6= Ws09vfM3lkubvtxgl3LxEaxrG4c4A35bJKP+pE7TR5sVU/QwTP2ic2psAckibYdJpWaGQOuqcXl= yY6MLNohM1RZt9FMwcIOCvftJi2ex+0ZmmnlozeGaGs5CYgQ5WfNJ3RIsXQk3nDjdzjcNYYJp9h= BKHNDnrAAmBsdiaBRr7RX0SO950pvW6PW+Rrt1cKOz/mxmgcPJallhM1s3DXENI26RXU5Q1em7X= ANpBBzYR1Ciz1hziAG0CIBpE47LqqJ6IUqWxCzeaAJos1vOeBiAbJJwSBTWAwLtWwyEAY9GcYq+= 90SyAqw0yLdOkTeDs2CkSWbeAJf1GZqwGsLThemDFc4IlWmZ5UQzHkuuYqwtsc2sFdlSYD1lM3Y= 4D5aIVG+eeP1Y6wMBNBks+JJ1WFAqpI/8jUBzFigE5UJI2EbOYz0ypyMBqS4B6e/u6pUBFDGGGc= wEXCNIbDP56k2bCX6BxXFWVf9hZFIwmHiZAnE+aHgZ+Wsylf+LmrOLkrUinMe30FX7SF4FpMYOj= BLoGRN+y2wSEvHhcPr9UpudA1XuU0TZrgASVTZ2xttHF7SgYTSwnQJwqDCMEhhm4s3EqriuprUD= PAvRpAEMgVpl9RyS99NbChf4P6ncbh0FUiBrS/drtFsttVY19MKDCTLfaHu0ddicjSB/rzCsH8k= rO+Q3bvykAoyB+UJ/wPybuT2KxDZw38jkwP0pA0EKuKaXtysIkL7/DLG3vCpQOZzIHP5yKHA1RB= t1ro6O6qNsCFArJc+CDeHvma2NzIFrOPlZgBSPyaiISi+9MWu8ZkRZD4pIld1widQSet3F2+iWO= 8Es1m/6u42cfh2vjlEIm/KCYTf/MjQWiQ05o3btMNcwN8xmaYRDfqmaVQSNbKCYvAZPY29q5Nwm= x9nNQo1KHa2OdzHb2sfO5eheaM/Iwg7cYu6QLnGzrVZ23zUlaiDnKEiWK/SnxocA8SRuMbLEAmn= c0F05W9QYjcoKIfgFgoQse0wrgxLM4Ls/3abSTgI0A/C7kCxKNGLsrWuBHAwN7P6rztPyy6rBWO= M4+boyqRlPnyA0g9DFxDMCnGhwaBXAMzC9oPt+v6ruRG7l1GlGXfAH/7SC6RVxEavtZHTBxzPsn= AX9m5lSlrB0cHDzwgVF+S4AcupnjOXY6jsxmWkeAqkW1PG83E75mdMLNQX82O+7WNkeAwrHEWmY= 8ZdGWXX0ScmvEbKabPNr3bAl0dJy6QFUV8QWAq18VSpTgyRuy8WAuSFzPPrPZeTe2TX72mf5By/= Lu40bhuUZTBcjhHGHyh4E3JL28olA4MHyuOTsTeycjqLevmwKVfgKuaSHEdoqdifJzgacKkNPKf= 8YJfgeErWpWef1ccOxs2VgDaHPXhDa2Q5wdAMxvWAFOAvxHBu0un77oZbtPI2fLmNkop+WgOBuN= /n/a5AHUAm0PIA+g9hLSiyAvgrwIag8BL4Law8+rQV4EeRHUHgJeBLWHn1eDvAhqL4L+C38I2WD= ElOGjAAAAAElFTkSuQmCC"/><= switch>
ACPI fixed
event active
<= g data-cell-id=3D"jeVlbFHk8Qahp5zcIn_D-43">
no
<= g data-cell-id=3D"jeVlbFHk8Qahp5zcIn_D-58">
yes
<= div data-drawio-colors=3D"color: #393C56; " style=3D"box-sizing: border-box= ; font-size: 0px; text-align: center;">
= IRQ other
than ACPI SCI active
<= /g>
no
yes
=
GPIO
IRQ shared
wit= h SCI
= no
<= path d=3D"M 321 1101 L 51 1101 L 51 407.37" fill=3D"none" stroke=3D"#e07a5f= " stroke-miterlimit=3D"10" pointer-events=3D"stroke"/>
yes
no
Any PM
wakeup event
pending
<= /switch>
Kernel resumes system
<= g data-cell-id=3D"jeVlbFHk8Qahp5zcIn_D-26"><= g>
uPEP driver removes O= S_HINT
<= path d=3D"M 151 651 L 51 651 L 51 407.37" fill=3D"none" stroke=3D"#e07a5f" = stroke-miterlimit=3D"10" pointer-events=3D"stroke"/>=
yes
<= /g>
no
<= div data-drawio-colors=3D"color: #393C56; " style=3D"box-sizing: border-box= ; font-size: 0px; text-align: center;">
= Any GPIO
w/ WAKESTS
active
<= /g>=
Check for ACPI Notify() event= s
<= path d=3D"M 371 1001 L 371 1044.63" fill=3D"none" stroke=3D"#e07a5f" stroke= -miterlimit=3D"10" pointer-events=3D"stroke"/>
yes
Any GPE
pending
=
OS moves active
core back to
ACPI C3
MP1 puts sy= stem back to sleep
 \ No newline at end of file diff --git a/Documentation/arch/x86/suspend.svg b/Documentation/arch/x86/su= spend.svg new file mode 100644 index 0000000000000..a69073c018d56 --- /dev/null +++ b/Documentation/arch/x86/suspend.svg @@ -0,0 +1,4 @@ + + + +
SFH driver notifies MP2 to stop all sensor collec= tion
no
=
Abort suspend; details logged in dmesg
Failures?
yes
no
yes
<= /switch>
All devices go into deepest D-state or F-state
=
Failures?
<= /g>
no
yes
GPIO driver suspends non-wake GPIOs
Suspend initiated from userspace
=
GPU driver shuts= down clocks and sends SMU messages
=
Failures?
=
ACPI s2idle driver notifies EC using _= DSM
=
uPEP driver (amd= -pmc) sends OS_HINT
=
Put all x86 CPU cores into ACPI C3
s2idle loop waiting for IRQ
to wake
=
no
Failures?
<= /switch><= foreignObject pointer-events=3D"none" width=3D"100%" height=3D"100%" requir= edFeatures=3D"http://www.w3.org/TR/SVG11/feature#Extensibility" style=3D"ov= erflow: visible; text-align: left;">
\ No newline at end of file --=20 2.43.0