From nobody Fri Dec 19 16:03:23 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 853A4128819; Tue, 15 Apr 2025 00:27:12 +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=1744676833; cv=none; b=HF/Tsg+S3x7a8u1QLyFwDOy9bPh5Lf49W7OBWV2j4IQ4Lp9SLM5gdD6s1E+YowwKga6vgaS/5uowkIQzSQUw4RRmDNcotHJIuFFeIljM3tMZNyFso3aKXnyiCGSWkeyW+O5pVH7oWxg55/Y1HfOAbMIyyuheUlQmB3nLr6dS73A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744676833; c=relaxed/simple; bh=ykn/Y1815nOvRCGTMiyAVTn5ycqabwFPRVebhZTUIlY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Rwod7piITQAX2QOxuPcxmc882/uwW/yCLB4EPipO/4Py3mI7Ikx8f+QtIAAbmfF1KzfQRqUcaky3kGMExMtjLt+GBKm9YIxO2QTiFO/qgVGUxQ+bjDHESSqP+gpca2bSABtafrdpAj6z3hX/o5v+7XSjFcrNwQwNF/84wE6UdWw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=datcJ6Ue; 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="datcJ6Ue" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44477C4CEEC; Tue, 15 Apr 2025 00:27:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744676832; bh=ykn/Y1815nOvRCGTMiyAVTn5ycqabwFPRVebhZTUIlY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=datcJ6Uefr4amBL5R9sGwFqgxQCirH+1puzkXbVSsSOwlq0o8fNpYQ+DLMKDDAkS9 LiOSOYhE+GBlBbPhYWLl4FS0bDFdPAY3ffJqtElFvzSmmu3by+S2NWGmf69SuE6+sN 6qoeNo29G7LFzl/YGlZggy4jCVNVacpSPx2YjHkVasBjvdGQYJRX6eW2aDRowW39vE c73do4cZ9/ay8mZMK6M0DcvN+jmeceYSvRamRjM/cBMeeIdzbV4pPhe3IKr2kHcdJC tZ2T3aQjsCGNt7/SOmU7gC3iHRZY+rkZutfB0z+0dcF/d8FTP2vEOhPFrvBVz0ozwL gzU6RoOkP+LMw== From: Mario Limonciello To: Borislav Petkov , Jean Delvare , Andi Shyti , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= 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 , Hans de Goede , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-i2c@vger.kernel.org (open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC), platform-driver-x86@vger.kernel.org (open list:AMD PMC DRIVER), "Gautham R . Shenoy" Subject: [PATCH v4 1/5] Documentation: Add AMD Zen debugging document Date: Mon, 14 Apr 2025 19:26:54 -0500 Message-ID: <20250415002658.1320419-2-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250415002658.1320419-1-superm1@kernel.org> References: <20250415002658.1320419-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 --- 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 | 273 +++++++++++++++++++++++ Documentation/arch/x86/index.rst | 1 + Documentation/arch/x86/resume.svg | 4 + Documentation/arch/x86/suspend.svg | 4 + 4 files changed, 282 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..ba99d672a1f4d --- /dev/null +++ b/Documentation/arch/x86/amd-debugging.rst @@ -0,0 +1,273 @@ +.. 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 script +=3D=3D=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 script `_ +has been created that can help test for common problems and offer suggesti= ons:: + + # git clone git://git.kernel.org/pub/scm/linux/kernel/git/superm1/amd-de= bug-tools.git + # cd amd-debug-tools + # sudo ./amd_s2idle.py + +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. diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/inde= x.rst index 56f2923f52597..6b5d35aa17939 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 tdx 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 From nobody Fri Dec 19 16:03:23 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 3F569140E5F; Tue, 15 Apr 2025 00:27:14 +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=1744676834; cv=none; b=jmmQMing0erOOKNho+vpUG7aL0reHDftNpF4jxEwG47BdTRmdsfyZ8Y/jaKZ2BevkQ1EXJ0B0rqE7PzJTl9l4wn08OmTvHfPXpNBvUwg5gYJ57GvP9c09rkAW0cILG1Mh7+hqSk8eqN71zMoMKvBS9fBZm2UhgZxu1U2nSb7Z9Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744676834; c=relaxed/simple; bh=EQbVFiXao7puD8FbTPpEU1eMmPNK8pXkKaFDejX7ioA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aqzqWQAgFKPtnDPl+l8fdc+HzMvitLeUSWg8zKkhFcunmnSWpgZIQuWtF0+4FY27wDlMGGwcmZcdgf+CjOkrUDBMYgcRAcAaN0C9i+bS3kBkkcIlG/8v2Z4RGEgam8Qc4W1hHi1IkcL8+oUIhDgkVkTLnpw+0mqVi456HcHXF1E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cwrOGu1l; 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="cwrOGu1l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D3DEC4CEE2; Tue, 15 Apr 2025 00:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744676834; bh=EQbVFiXao7puD8FbTPpEU1eMmPNK8pXkKaFDejX7ioA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cwrOGu1lECI6l1OWhS0hTHi3FQWoStrJZ+Rhh6tSJIucoAw3nYduIFqPfjpaof+Qe Eow4a6h9ZMO493i0K0k4L+zgtOrnSJ9tKEONLxOY+bqNqtTn3oSjf2SunqJb96yA3y SEjyG3RNC1RNqpt7kZy1KCkRdDTNO/kDgYgsaVjUEuVqkvcoiEA/g2kCReuTWMybOy e9kMgXUOqW3UwwyVFQ761bzxnOQfaP/6eovvNJxpSzARHzGZQb1GnIp1aHd59+W6NK EMdfJO/Eh6ZSgyGTQasc6XQSX7u3VW26bfthiOLEZ55p8mxx7XMiNmd0IEp6A79uUQ btu50S5KKIwdg== From: Mario Limonciello To: Borislav Petkov , Jean Delvare , Andi Shyti , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= 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 , Hans de Goede , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-i2c@vger.kernel.org (open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC), platform-driver-x86@vger.kernel.org (open list:AMD PMC DRIVER), kernel test robot , Ingo Molnar Subject: [PATCH v4 2/5] i2c: piix4: Depends on X86 Date: Mon, 14 Apr 2025 19:26:55 -0500 Message-ID: <20250415002658.1320419-3-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250415002658.1320419-1-superm1@kernel.org> References: <20250415002658.1320419-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 PIIX4 and compatible controllers are only for X86. As some headers are being moved into x86 specific headers PIIX4 won't compile on non-x86. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202504120558.sq3IpWdH-lkp@int= el.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202504120432.0F8lOF3k-lkp@int= el.com/ Suggested-by: Ingo Molnar Signed-off-by: Mario Limonciello --- drivers/i2c/busses/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 83c88c79afe20..bbbd6240fa6ed 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -200,7 +200,7 @@ config I2C_ISMT =20 config I2C_PIIX4 tristate "Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC)" - depends on PCI && HAS_IOPORT + depends on PCI && HAS_IOPORT && X86 select I2C_SMBUS help If you say yes to this option, support will be included for the Intel --=20 2.43.0 From nobody Fri Dec 19 16:03:23 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 9489F1531D5; Tue, 15 Apr 2025 00:27:16 +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=1744676836; cv=none; b=eckxuK7iwnruudFlPJeC8t6GsQeDNVCHqjpcXKTgc9qrIvPn3mYU/m7beaiNUT2dnhbYKglYsrmkyADoBzGRKf+0KCc4JL30MSdazCn4usHASEfImk/evz/NUCffSH0q/FKpd+TTyt5yDrv05vfrNUOTD4DM6W8OJq9g7MIpizo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744676836; c=relaxed/simple; bh=OhRAvfI5XC0roD7CJN4SDA+Hiq02+jE5bWTG/sHe7hQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JahYjCDNCd20CMZz9+F1kgWOXJtYgFOxbuYZAWelVxePbOr1tJRbm5y2HPzzNHN/8ZDveb6be/+mWesx3cnyXGAxuK+YEJcuu1tit9cYpOqk2uVztjePeZ6OrQsHao2c8V5q6RE1ASHczF0R6hHe4pqDe/V1KIbWPWgq6wlJiBc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YblKGOIP; 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="YblKGOIP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F1AAC4CEF0; Tue, 15 Apr 2025 00:27:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744676836; bh=OhRAvfI5XC0roD7CJN4SDA+Hiq02+jE5bWTG/sHe7hQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YblKGOIPqfxUFcwFWOULnOwi0UjojhmjPfoVu1t80Qwh1dR2Ob9XP5z0lnj7OBT12 ncsZjGcc//8pOCRFNasP/uF8jbisI6wrzGaGjtNPWpt3Tu2iZ7Sa9tjyEp5LcdhZUX f79Q9L5lQ1pCMmJQdKeJMSSrSuFmMxMBqW3q/sqY8ecHoCgGPBOBjhPGzNCIq2jS1+ yiNTm7sDnbCt1cXb9sh7dQ7hXTIKHWJ8wAjYc8PTujlm0frWL/c35OXCVrKy6lvWXV jLCnUZvUgDGkoYkW+lYEKeuGt2IFtn5T8G8Kh8dyU/rqjgmyjHNM+7KzFzVZMJ++V7 CvaSqnOQT1r6g== From: Mario Limonciello To: Borislav Petkov , Jean Delvare , Andi Shyti , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= 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 , Hans de Goede , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-i2c@vger.kernel.org (open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC), platform-driver-x86@vger.kernel.org (open list:AMD PMC DRIVER) Subject: [PATCH v4 3/5] i2c: piix4: Move SB800_PIIX4_FCH_PM_ADDR definition to amd/fch.h Date: Mon, 14 Apr 2025 19:26:56 -0500 Message-ID: <20250415002658.1320419-4-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250415002658.1320419-1-superm1@kernel.org> References: <20250415002658.1320419-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 SB800_PIIX4_FCH_PM_ADDR is used to indicate the base address for the FCH PM registers. Multiple drivers may need this base address, so move it to a common header location and rename accordingly. Signed-off-by: Mario Limonciello --- v4: * Move FCH_PM_DECODEEN to fch.h, but shift it for use in piix4 because piix4 does 8 bit reads --- arch/x86/include/asm/amd/fch.h | 12 ++++++++++++ drivers/i2c/busses/i2c-piix4.c | 18 +++++++++--------- 2 files changed, 21 insertions(+), 9 deletions(-) create mode 100644 arch/x86/include/asm/amd/fch.h diff --git a/arch/x86/include/asm/amd/fch.h b/arch/x86/include/asm/amd/fch.h new file mode 100644 index 0000000000000..a5fd91ff92df3 --- /dev/null +++ b/arch/x86/include/asm/amd/fch.h @@ -0,0 +1,12 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +#ifndef _ASM_X86_AMD_FCH_H_ +#define _ASM_X86_AMD_FCH_H_ + +#define FCH_PM_BASE 0xFED80300 + +/* register offsets from PM base */ +#define FCH_PM_DECODEEN 0x00 +#define FCH_PM_DECODEEN_SMBUS0SEL GENMASK(20, 19) + +#endif diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c index dd75916157f05..6350003de32b1 100644 --- a/drivers/i2c/busses/i2c-piix4.c +++ b/drivers/i2c/busses/i2c-piix4.c @@ -21,6 +21,7 @@ an i2c_algorithm to access them. */ =20 +#include #include #include #include @@ -80,12 +81,11 @@ #define SB800_PIIX4_PORT_IDX_MASK 0x06 #define SB800_PIIX4_PORT_IDX_SHIFT 1 =20 -/* On kerncz and Hudson2, SmBus0Sel is at bit 20:19 of PMx00 DecodeEn */ -#define SB800_PIIX4_PORT_IDX_KERNCZ 0x02 -#define SB800_PIIX4_PORT_IDX_MASK_KERNCZ 0x18 +/* SmBus0Sel is at bit 20:19 of PMx00 DecodeEn */ +#define SB800_PIIX4_PORT_IDX_KERNCZ (FCH_PM_DECODEEN + 0x02) +#define SB800_PIIX4_PORT_IDX_MASK_KERNCZ (FCH_PM_DECODEEN_SMBUS0SEL >> 16) #define SB800_PIIX4_PORT_IDX_SHIFT_KERNCZ 3 =20 -#define SB800_PIIX4_FCH_PM_ADDR 0xFED80300 #define SB800_PIIX4_FCH_PM_SIZE 8 #define SB800_ASF_ACPI_PATH "\\_SB.ASFC" =20 @@ -162,19 +162,19 @@ int piix4_sb800_region_request(struct device *dev, st= ruct sb800_mmio_cfg *mmio_c if (mmio_cfg->use_mmio) { void __iomem *addr; =20 - if (!request_mem_region_muxed(SB800_PIIX4_FCH_PM_ADDR, + if (!request_mem_region_muxed(FCH_PM_BASE, SB800_PIIX4_FCH_PM_SIZE, "sb800_piix4_smb")) { dev_err(dev, "SMBus base address memory region 0x%x already in use.\n", - SB800_PIIX4_FCH_PM_ADDR); + FCH_PM_BASE); return -EBUSY; } =20 - addr =3D ioremap(SB800_PIIX4_FCH_PM_ADDR, + addr =3D ioremap(FCH_PM_BASE, SB800_PIIX4_FCH_PM_SIZE); if (!addr) { - release_mem_region(SB800_PIIX4_FCH_PM_ADDR, + release_mem_region(FCH_PM_BASE, SB800_PIIX4_FCH_PM_SIZE); dev_err(dev, "SMBus base address mapping failed.\n"); return -ENOMEM; @@ -201,7 +201,7 @@ void piix4_sb800_region_release(struct device *dev, str= uct sb800_mmio_cfg *mmio_ { if (mmio_cfg->use_mmio) { iounmap(mmio_cfg->addr); - release_mem_region(SB800_PIIX4_FCH_PM_ADDR, + release_mem_region(FCH_PM_BASE, SB800_PIIX4_FCH_PM_SIZE); return; } --=20 2.43.0 From nobody Fri Dec 19 16:03:23 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 903A0664C6; Tue, 15 Apr 2025 00:27:18 +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=1744676838; cv=none; b=WIur/lqFaLmc1juChLHcAoIszJZYY2iSSuNwkC78DqpgPPWCfFgtf9qGtEx6YM4o+c3EQV5kuSHxLTAFaoBN2BsKlFxr9fHg25EkfvMdKTNbFZg04CjNFbUOZMKsWTS4iw6ACqMKYD0WER9N6xOlSxsqCYVAJQFOCCAIMO3gIS8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744676838; c=relaxed/simple; bh=3PZGgeloL2FPnEpZbWe+5dkglLcVFWEmJTDvvWazHA4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DebBf5fHBNbVcyl6Rc4KCQRXPNPUZYCmXGOXtXNbKZqel+N4qTpmmFd9pjBPyZ3rC9nr+/6/Z6EUbopP5z1HaJCmZro6YWf6Q8ErKxXgmWYXM3/qvXHvMagE3Mh0VlhcpnzIF+a0BCPDwi42hpuMCZy1hHwsX8iLseYO5h9Dit0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G8DveNRn; 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="G8DveNRn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53949C4CEEA; Tue, 15 Apr 2025 00:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744676838; bh=3PZGgeloL2FPnEpZbWe+5dkglLcVFWEmJTDvvWazHA4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G8DveNRngd6VcmpueND/VjYEA6n11bdZ+b7vZlU3c2gUXIBFccWzevvlEpnE25rVx chI/0YyWFGvFIu8Zt/nhmqZsCgp7pQbBO4NmBCs+n/DRwpzAlkfRPi/Vo7YTp2/Av7 vum5f6i5HIydYOMQKPpUh3xFCQ7brsO67bhCPLjkf1Z8vr0q9XKkiekDgsZp4hKHgV mVcPRDyBf4OnnRJr+PfS/RPfeRQ67wTcMIqRERsB+bx7CVefsV1FXQ2USjB875kHa6 5dMstpjA/zVH4G+8HY0sMxk1Mp2CFycu/fEC8XRF3vObSvY+sbRr4qPGmkV+nV6eoZ I+9emxkj46VzQ== From: Mario Limonciello To: Borislav Petkov , Jean Delvare , Andi Shyti , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= 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 , Hans de Goede , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-i2c@vger.kernel.org (open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC), platform-driver-x86@vger.kernel.org (open list:AMD PMC DRIVER) Subject: [PATCH v4 4/5] platform/x86/amd: pmc: use FCH_PM_BASE definition Date: Mon, 14 Apr 2025 19:26:57 -0500 Message-ID: <20250415002658.1320419-5-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250415002658.1320419-1-superm1@kernel.org> References: <20250415002658.1320419-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 The s2idle mmio quirk uses a scratch register in the FCH. Adjust the code to clarify that. Signed-off-by: Mario Limonciello --- v4: * Use fch.h instead --- arch/x86/include/asm/amd/fch.h | 1 + drivers/platform/x86/amd/pmc/pmc-quirks.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/amd/fch.h b/arch/x86/include/asm/amd/fch.h index a5fd91ff92df3..9b32e8a03193e 100644 --- a/arch/x86/include/asm/amd/fch.h +++ b/arch/x86/include/asm/amd/fch.h @@ -8,5 +8,6 @@ /* register offsets from PM base */ #define FCH_PM_DECODEEN 0x00 #define FCH_PM_DECODEEN_SMBUS0SEL GENMASK(20, 19) +#define FCH_PM_SCRATCH 0x80 =20 #endif diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x= 86/amd/pmc/pmc-quirks.c index b4f49720c87f6..3c680d2029f62 100644 --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c @@ -8,6 +8,7 @@ * Author: Mario Limonciello */ =20 +#include #include #include #include @@ -20,7 +21,7 @@ struct quirk_entry { }; =20 static struct quirk_entry quirk_s2idle_bug =3D { - .s2idle_bug_mmio =3D 0xfed80380, + .s2idle_bug_mmio =3D FCH_PM_BASE + FCH_PM_SCRATCH, }; =20 static struct quirk_entry quirk_spurious_8042 =3D { --=20 2.43.0 From nobody Fri Dec 19 16:03:23 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 2919A176ADB; Tue, 15 Apr 2025 00:27:20 +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=1744676840; cv=none; b=MgEcf89IQ8g75IrhXj1CsUqNn65xEqlcrA0xnjJst5SOvHmm165euXUzf+SyKnmHuB9XywYVji+wIRgDhXvCjZAYAgzRi3izNGmP0pZyrzeONnJ3iftZ6rek6m1M2MIwNrFgaxaaUTurY9teqQd8gcUbH0xGD+BijOcM0B/Pvng= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1744676840; c=relaxed/simple; bh=kqMU7kGHOah8Smsm3vfblSteI+QgRbx0dqIFMAGWhWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ivz12EDnuJWUP7SNnNOVnPLYlPHesuUZcQWFrCiokvVay2B9dMjVKZNZE0kFt8a88jrgtwHyFB5N7Ts39K45ezH3PqsnXh6mKEt0iaXQ0VaHqYD6vFl087YgV/wQ2rKcEUqM20dtkqZb/iuKcUI7iaMNUknxA/eHiL/BmHqrdxQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kxUBHhRu; 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="kxUBHhRu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C017C4CEE2; Tue, 15 Apr 2025 00:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744676840; bh=kqMU7kGHOah8Smsm3vfblSteI+QgRbx0dqIFMAGWhWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kxUBHhRuu1Z+DN2A/bcFdh4BLuSfTN7MIZy1IJchqHZMeZ4wvMX/Nez3yLtpkO7Zk TzVDqo9RVicqPyY+DY+AJFxxwZ0uQNOxRTF+8zuEEqGmRewmT3SkYpsv7z0aVM+lFk BoUW0Uuml/PhheOvm6f8hoqRzX69jWqaP5pg5ratM8jw7ziKGutyrqoJFGZ4mw2xyG 3z7YweVW2OkxXmGSOKnoITb+VW7rYcguroX7YbXOjOD8eYP6rin093jh1MUae8t1DF pFKXQ85XW+1P5PNFRtJedQMDqs8XLuHIFwJO9Ppyornflj/9RTRybB7gkAHCQPmm3h wxmDTsYAvkRPg== From: Mario Limonciello To: Borislav Petkov , Jean Delvare , Andi Shyti , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= 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 , Hans de Goede , linux-doc@vger.kernel.org (open list:DOCUMENTATION), linux-kernel@vger.kernel.org (open list), linux-i2c@vger.kernel.org (open list:I2C/SMBUS CONTROLLER DRIVERS FOR PC), platform-driver-x86@vger.kernel.org (open list:AMD PMC DRIVER) Subject: [PATCH v4 5/5] x86/CPU/AMD: Print the reason for the last reset Date: Mon, 14 Apr 2025 19:26:58 -0500 Message-ID: <20250415002658.1320419-6-superm1@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20250415002658.1320419-1-superm1@kernel.org> References: <20250415002658.1320419-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: Yazen Ghannam The following register contains bits that indicate the cause for the previous reset. PMx000000C0 (FCH::PM::S5_RESET_STATUS) This is useful for debug. The reasons for reset are broken into 6 high level categories. Decode it by category and print during boot. Specifics within a category are split off into debugging documentation. The register is accessed indirectly through a "PM" port in the FCH. Use MMIO access in order to avoid restrictions with legacy port access. Use a late_initcall() to ensure that MMIO has been set up before trying to access the register. This register was introduced with AMD Family 17h, so avoid access on older families. There is no CPUID feature bit for this register. Signed-off-by: Yazen Ghannam Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello --- v4: * Use loop that can output multiple reasons * Drop "Unknown" condition and have dedicated message v3: * Align strings in the CSV and code. * Switch to an array of strings * Switch to looking up bit of first value * Re-order message to have number first (makes grepping easier) * Add x86/amd prefix to message v2: * Add string for each reason, but still include value in case multiple values are set. --- Documentation/arch/x86/amd-debugging.rst | 42 ++++++++++++++++ arch/x86/include/asm/amd/fch.h | 1 + arch/x86/kernel/cpu/amd.c | 64 ++++++++++++++++++++++++ 3 files changed, 107 insertions(+) diff --git a/Documentation/arch/x86/amd-debugging.rst b/Documentation/arch/= x86/amd-debugging.rst index ba99d672a1f4d..48c03b04fc4ab 100644 --- a/Documentation/arch/x86/amd-debugging.rst +++ b/Documentation/arch/x86/amd-debugging.rst @@ -271,3 +271,45 @@ 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. + +Random reboot issues +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +When a random reboot occurs, the high-level reason for the reboot is stored +in a register that will persist onto the next boot. + +There are 6 classes of reasons for the reboot: + * Software induced + * Power state transition + * Pin induced + * Hardware induced + * Remote reset + * Internal CPU event + +.. csv-table:: + :header: "Bit", "Type", "Reason" + :align: left + + "0", "Pin", "thermal pin BP_THERMTRIP_L was tripped" + "1", "Pin", "power button was pressed for 4 seconds" + "2", "Pin", "shutdown pin was shorted" + "4", "Remote", "remote ASF power off command was received" + "9", "Internal", "internal CPU thermal limit was tripped" + "16", "Pin", "system reset pin BP_SYS_RST_L was tripped" + "17", "Software", "software issued PCI reset" + "18", "Software", "software wrote 0x4 to reset control register 0xCF9" + "19", "Software", "software wrote 0x6 to reset control register 0xCF9" + "20", "Software", "software wrote 0xE to reset control register 0xCF9" + "21", "Sleep", "ACPI power state transition occurred" + "22", "Pin", "keyboard reset pin KB_RST_L was asserted" + "23", "Internal", "internal CPU shutdown event occurred" + "24", "Hardware", "system failed to boot before failed boot timer expir= ed" + "25", "Hardware", "hardware watchdog timer expired" + "26", "Remote", "remote ASF reset command was received" + "27", "Internal", "an uncorrected error caused a data fabric sync flood= event" + "29", "Internal", "FCH and MP1 failed warm reset handshake" + "30", "Internal", "a parity error occurred" + "31", "Internal", "a software sync flood event occurred" + +This information is read by the kernel at bootup and is saved into the +kernel ring buffer. When a random reboot occurs this message can be helpful +to determine the next component to debug such an issue. diff --git a/arch/x86/include/asm/amd/fch.h b/arch/x86/include/asm/amd/fch.h index 9b32e8a03193e..4a6e1e3b685a4 100644 --- a/arch/x86/include/asm/amd/fch.h +++ b/arch/x86/include/asm/amd/fch.h @@ -9,5 +9,6 @@ #define FCH_PM_DECODEEN 0x00 #define FCH_PM_DECODEEN_SMBUS0SEL GENMASK(20, 19) #define FCH_PM_SCRATCH 0x80 +#define FCH_PM_S5_RESET_STATUS 0xC0 =20 #endif diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index a839ff506f454..32ecb70cce5dc 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -1232,3 +1233,66 @@ void amd_check_microcode(void) if (cpu_feature_enabled(X86_FEATURE_ZEN2)) on_each_cpu(zenbleed_check_cpu, NULL, 1); } + +static const char * const s5_reset_reason_txt[] =3D { + [0] =3D "thermal pin BP_THERMTRIP_L was tripped", + [1] =3D "power button was pressed for 4 seconds", + [2] =3D "shutdown pin was shorted", + [4] =3D "remote ASF power off command was received", + [9] =3D "internal CPU thermal limit was tripped", + [16] =3D "system reset pin BP_SYS_RST_L was tripped", + [17] =3D "software issued PCI reset", + [18] =3D "software wrote 0x4 to reset control register 0xCF9", + [19] =3D "software wrote 0x6 to reset control register 0xCF9", + [20] =3D "software wrote 0xE to reset control register 0xCF9", + [21] =3D "ACPI power state transition occurred", + [22] =3D "keyboard reset pin KB_RST_L was asserted", + [23] =3D "internal CPU shutdown event occurred", + [24] =3D "system failed to boot before failed boot timer expired", + [25] =3D "hardware watchdog timer expired", + [26] =3D "remote ASF reset command was received", + [27] =3D "an uncorrected error caused a data fabric sync flood event", + [29] =3D "FCH and MP1 failed warm reset handshake", + [30] =3D "a parity error occurred", + [31] =3D "a software sync flood event occurred", +}; + +static __init int print_s5_reset_status_mmio(void) +{ + void __iomem *addr; + unsigned long value; + int nr_reasons =3D 0; + int bit =3D -1; + + if (!cpu_feature_enabled(X86_FEATURE_ZEN)) + return 0; + + addr =3D ioremap(FCH_PM_BASE + FCH_PM_S5_RESET_STATUS, sizeof(value)); + if (!addr) + return 0; + + value =3D ioread32(addr); + iounmap(addr); + + /* Iterate on each bit in the 'value' mask: */ + while (true) { + bit =3D find_next_bit(&value, BITS_PER_LONG, bit + 1); + + /* Reached the end of the word, no more bits: */ + if (bit >=3D BITS_PER_LONG) { + if (!nr_reasons) + pr_info("x86/amd: Previous system reset reason [0x%08lx]: Unknown\n", = value); + break; + } + + if (!s5_reset_reason_txt[bit]) + continue; + + nr_reasons++; + pr_info("x86/amd: Previous system reset reason [0x%08lx]: %s\n", + value, s5_reset_reason_txt[bit]); + } + + return 0; +} +late_initcall(print_s5_reset_status_mmio); --=20 2.43.0