Repository navigation
Conversation
The PMP's firmware runs from the moment its driver starts it, and in a suspend-to-idle the driver leaves it running: only a firmware-driven sleep stops it. Its three power states were ordinary genpd domains, though, so at the noirq phase of every s2idle genpd gated the PMP's core (pmp) and its SRAM (pms-sram) under the running firmware and then tried their parent (pms), which the PMGR refuses: PS pms: Failed to reach power state 0x0 (requested 0xf0000f0, now: 0x1f0002ff) With power back at the wake the firmware usually takes a translation fault within the first moments (PC 0x10178b4, 0x1025498 or 0, every register zero) and reports a crash; it stays down until reboot, and prints its crash log again at each later wake. On the K116s that was 3 of the 4 suspends that reached the noirq phase with a live PMP. Mark all three always-on, as the ADT's "critical" flag on PMP asks. Every other SoC description with a pms domain keeps it on, and those whose PMP Linux runs (T6030, T604x, T8122, T8132, T8140 and the T8142 J813, which gained it for the same crash) keep pmp on. The PMP then keeps running through s2idle as it does under macOS, and the pms message goes away with the power-off request. Signed-off-by: Jens Axboe <axboe@kernel.dk> [thomas: name the SoCs that keep pms and pmp on] Signed-off-by: Thomas Glanzmann <thomas@glanzmann.de>
Contributor
|
More cycles on the K116s (16" M5 Pro OLED, 27.2 stub, Linux at EL2) with this change: 4 s2idle cycles so far, all clean. No
Each was a lid close/open of 10 to 20 s. Before the change every suspend on this machine logged the PS failure and the PMP crashed on wake. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Base: integration/aurora (673f618). Branch thomas/t6050-pmp-always-on, one commit.
arm64: dts: apple: t6050: keep the PMP's power domains on.
What went wrong: the PMP firmware runs from the moment its driver starts it, and s2idle leaves it running. But pms, pmp and pms-sram were ordinary genpd domains, so at the noirq phase of every s2idle genpd gated pmp and pms-sram under the running firmware. It then tried their parent pms, which the PMGR refuses:
At the wake the firmware usually takes a translation fault and stays down until reboot. On the K116s, that happened in 3 of the 4 suspends that reached the noirq phase with a live PMP.
The change: all three domains are marked
apple,always-on, as the ADT's "critical" flag on PMP asks.Commit message: I changed that sentence, which originally said every other SoC does both, with a
[thomas: …]note.Boards affected: the domains are in t6050-peripherals.dtsi.
Testing:
scripts/dtc/apple-dt-check.sh673f618 against this branch: 0 new warnings, 0 removed, all 137 Apple DTBs build. (dt-validate cannot decode the J714s DTB at all, see arm64: dts: apple: t6050-k116s: N1, USB-C, SMC, DCP, sound, PMP/SEP, GPU, SD reader, microphones, camera #1648, so that board is not covered by this check.)Authorship: Jens Axboe wrote it on his K116s (Mac17,12, stub macOS 27.2 26B8125). It is from his second update of 2026-11-12, and it carries his Signed-off-by and mine.
cc @Acelogic @DjDeveloperr @RyanTheTide @LiamRay10