Repository navigation
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
…without it The PD controllers on the M1 Pro/Max laptops report a DP alt mode state at probe for ports that have no display behind them, for example an empty port or one with only a charger. With the crossbar driver in the initramfs appledrm binds about a second into boot, and whichever port is routed first gets the Type-C pipeline. If that is the wrong one, the port with the display finds every pipeline taken (-ENOSPC, which the CD321x driver does not retry) and stays dark for the whole boot, which puts the LUKS prompt on the internal panel of a closed laptop. When a port whose sink asserts HPD finds no free pipeline, release one held by a port whose sink never asserted HPD and take it. Tunnels, ports with a pending safe state and pipelines whose fixed output is in use are left alone. The released port drops its applied state so its next update is routed again once a pipeline is free. Link: omacom/omarchy-pkgs#1037 Signed-off-by: Andreas Fernandez <[email protected]>
Ante042
force-pushed
the
dcp-typec-hpd-takeover
branch
from
October 16, 2026 15:55
51481d1 to
53397b7
Compare
Author
|
Closing in favour of omacom/linux-aurora#186, which carries the same takeover on top of the 7.2 fabric together with two follow-ups. |
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.
On the M1 Pro the PD controllers report a DP alt mode state at probe even for ports with no display behind them, like an empty port or one that only has the charger in it. Once the crossbar driver is in the initramfs, appledrm binds about a second into boot, and whichever port gets routed first takes the only Type-C pipeline. When that is the wrong port, the one with the monitor gets -EBUSY ("failed to configure Type-C mux: -16") and stays dark for the rest of the boot. In clamshell mode that puts the LUKS prompt on a panel you can't see. It happened in about half of my boots. The logs are in omacom/omarchy-pkgs#1037.
With this patch, a port whose sink asserts HPD and finds no free pipeline can take one over from a port whose sink never asserted HPD. Tunnels, ports with a pending safe state and pipelines whose fixed HDMI output is live are left alone. The port that loses its pipeline clears its applied state, so its next update gets routed again once a pipeline frees up. On t602x the keep_order path already handles this once a compositor is up, so this mostly matters for t600x and for early boot.
I've been running the fe6d813 version of this on a J314s since 2026-10-13. Boots where the display port wins the race on its own are unchanged, and in 3 of the last 12 boots the takeover kicked in ("released Type-C DPTX PHY 2 held without HPD") and the monitor behind it came up normally. The aurora-wip version is the same logic moved into a helper, because dcp_typec_route_set() has changed since then.
Happy to adjust it if you'd rather solve this somewhere else, and I can test any changes on the J314s.