Repository navigation
T8140: USB-C PHY lock and NI error status after DRAM-kept wakes - #1266
Closed
DjDeveloperr wants to merge 7 commits into
Closed
DjDeveloperr wants to merge 7 commits into
DjDeveloperr wants to merge 7 commits into
Conversation
After a sleep that keeps the USB host's always-on side, the wake holds
the power control's PHY lock (pwrctl +0x18, acknowledged in +0x1c)
around the common block's USB3 setup. It was never acknowledged
("PHY lock request not acknowledged: 0x0"): the entry had parked the
PIPE on the dummy backend, and on the J700 the lock is only
acknowledged with the PIPE on the USB3 PHY (measured). macOS leaves
the PIPE on the USB3 PHY through its sleep (measured). The park at
the entry wasn't acknowledged either, as the controller is halted by
then, and went ahead unlocked on every sleep.
Leave the PIPE where it is for the hibernation, and park it at the
wake instead, under the PHY lock and with the controller's core still
in reset, before the common block is set up again. That's the state
the USB3 routing after the wake starts from, as after a wake that lost
the always-on side.
Signed-off-by: Diljit Singh <hey@djdev.me>
The T8140 data is interrupt-only, so a latched fabric NI error keeps its line asserted. After a sleep that keeps DRAM up, SoC NI 1 reports a link error on its PCIe port (0x80 in +0x1b58), and the line fires under the backoff until it's masked for good. Map the six NI apertures, from the ADT's niN-metadata, and on an NI interrupt read its status words, from macOS's decoder tables. Log each word that's set and acknowledge it by writing the bits back, as on T6041. A line whose status cleared stays unmasked; anything else goes through the backoff as before. On the J700 the write-back clears the word and the line stays quiet. Signed-off-by: Diljit Singh <hey@djdev.me>
…ddr-wake Keep the T8140 NI aperture table and acknowledge path next to #1304's T6000 error and T6000/T8112 event-log handlers in apple_soc_edac.c.
…-edac-slpddr-wake Brings in #1208's aop-bootargs host test fix. No conflicts. Signed-off-by: Diljit Singh <hey@djdev.me>
…ddr-wake Signed-off-by: Diljit Singh <hey@djdev.me>
Contributor
Author
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.
Two fixes for what the J700 logs after a sleep that keeps DRAM up (every sleep after the first of a boot). Both also show on #1217 without #1265.
USB-C PHY: "PHY lock request not acknowledged: 0x0" (ATC0, 40b000000.phy)
Cause: the wake holds the controller power control's PHY lock (pwrctl +0x18, ack in +0x1c) around the USB3 setup. A deep wake loses the always-on side, so the lock is never asked for there. Measured on the J700, the lock is acknowledged only with the PIPE on the USB3 PHY, and the sleep entry had parked it on the dummy backend. That park was never acknowledged either: the halted controller doesn't answer the PIPE lock, so it went ahead unlocked on every sleep. macOS leaves the PIPE on the USB3 PHY for its sleep (measured).
Fix: leave the PIPE where it is for the hibernation. Park it at the wake instead, under the PHY lock with the core still in reset, before the common block is set up again.
apple_soc_edac: "ni1 source 19", line left asserted
Cause: this is a real fabric error, not caused by the PHY. It's SoC NI 1 LINK_ERR, PCIE_RXL (0x80 at +0x1b58), on the radio/ANS PCIe slice; USB sits on SoC NI 2, which stays quiet. It latches during the sleep itself: the word reads 0 at the commit and after the APCIe block goes down, and 0x80 at the wake before anything runs. The deep path resets the fabric, so it's only seen on DRAM-kept wakes. The T8140 data was interrupt-only, so nothing cleared it.
Fix: map the six NI apertures (ADT niN-metadata) and read their status words (macOS's decoder tables) on an NI interrupt. Log the set words and acknowledge them by writing the bits back, as on T6041. Where the PCIe link error comes from in the sleep isn't fixed here.
Hardware result (J700, production command line, SEP active):
5 sleeps, all rc 0. After every wake: NVMe direct I/O matched, the same USB devices, Wi-Fi up with the gateway answering, the panel on. HPAI and LPAI record after the sleeps.
🤖 Generated with Claude Code