Repository navigation
Conversation
…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 a dock without a display. Whichever port is routed first gets a Type-C pipeline. If that is the wrong one, the port with the display finds every pipeline taken (-ENOSPC) and stays dark until the other port is unplugged, which can also put 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 direct DP-alt 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 <andreas.fernandez@hotmail.com>
Outside compositor pairing order, a direct DP-alt port takes the lowest free pipeline as soon as it enters DP mode, whether or not a display is behind it. A USB-C dock without a display does exactly that, and on an M1 Pro with two pipelines it leaves one display dark when it is plugged in before them. The previous patch can take the pipeline back, but a hand-over 6 ms after the dock's route was set left the firmware's DPTX service on that DCP answering -110 until reboot. Leave a port that owns no pipeline and has no HPD unrouted, and route it when the port controller reports HPD as a new status. A port that already owns a pipeline keeps it across an HPD drop, as before, and the compositor-ordered path is unchanged. Signed-off-by: Andreas Fernandez <andreas.fernandez@hotmail.com>
The DCP fabric now reports a port without a pipeline as -ENOSPC on every SoC, but cd321x_display_taken() only accepts it on H17 and expects -EBUSY elsewhere. On an M1 Pro, a dock in DP alt mode with both pipelines driving other displays gets "failed to configure Type-C connection: -28" three times, the cable revalidation fails and the USB role is never set, so everything behind the dock is gone. Accept -ENOSPC as a taken display everywhere and keep -EBUSY as one outside H17 for older fabrics. Signed-off-by: Andreas Fernandez <andreas.fernandez@hotmail.com>
 [Medium impact] The PR appears safe to merge. SummaryKeeps direct DP-alt ports without HPD from taking a display pipeline.
No actionable issues were found.
|
|
The third commit here ( The two differ in one point:
From the code, both fix the T8112 case, because the fabric reports Only one of the two should be merged. If this one goes in, #163 can be closed. |
|
Tested on the lab laptops as part of a combined hand build (also carrying 183, 179, 202; each PR's contribution is called out below). Posted here for 186. What was built
Results (candidate boots, one-shot, stock untouched otherwise) Per machine: ssh up, systemd running with 0 failed units, smoke suite equal to that machine's own stock baseline of the same day (wifi, input, display, audio tone, ANE, battery; gpu and seat-audio script limits identical to baseline), gpu-compute max_abs_err identical to baseline, DCP probe lines clean (zero dcp/tipd error lines on candidate boots on both machines; no dcp-fabric or cd321x warnings appeared), error-class diff vs the same machine's stock baseline shows no new class (only known 7.2.11-base/flake lines: tas2764 probe, of_irq, brcmf assoc/roam). Backlight set/readback and display connectors unchanged. Regressions: none found on T8103/T6021. Not yet run: the 16-inch M1 Max machine (its lab window was taken by other tests); I will add one line to this comment thread when it ran. Not covered by this test: machines with T8140/T8142-class tipd behaviour the PR calls out (no such hardware here); no external display/Dock was hot-plugged during the candidate boots (the PR's DP-alt no-display path was not exercised with a live pipeline change; the driver compiled in and bound without errors). The tipd KUnit tests were not run on hardware (CI/host test coverage is separate). |
|
Related J615 combined-stack hardware evidence and limits: #163 (comment) . The local tested stack includes deferred routing when HPD is absent, but uses the #163-style -ENOSPC-only contention predicate rather than the older-SoC -EBUSY alternative. These TIPD policies need reconciliation rather than merging both unchanged. Also see the reclaim error-propagation concern: #357 (comment) . The successful user-reported lid/replug use does not establish error-path or provider-order correctness. |
Hi! These three come from running two USB-C displays and a USB-C dock on an M1 Pro (J314s) with the Omarchy kernel. Outside compositor pairing order, a port in DP alt mode takes a pipeline as soon as it enters DP mode, even when nothing behind it asserts HPD. A dock without a display does exactly that, and with two pipelines one of the displays stays dark. It also happens at boot, when the PD controllers report a DP state for ports with nothing behind them, which is how the LUKS prompt ends up on the internal panel of a closed laptop (omarchy-pkgs#1037).
The first patch lets a port with HPD take over a pipeline held by a port that never asserted it. The second keeps such a port unrouted until its sink asserts HPD, so the takeover is only left for corner cases. Once, a hand-over right after the dock had been routed left the DPTX service on that DCP answering -110 until reboot. The third is in tipd: the fabric now reports a port without a pipeline as -ENOSPC on every SoC, but cd321x_display_taken() only accepts that on H17. On t600x the dock's DP setup failed with -28 three times, the cable revalidation failed and nothing behind the dock came up.
I've been running the takeover and the tipd change on 7.2.10 since the 20th and the second patch since the 22nd. The setup is a ROG and a VG278 on two ports and the dock on the third. Both displays come up at boot and after replugs, the dock never gets a pipeline, and its USB works. The patches are rebased onto 42672ed and build against 7.2.11. Happy to test anything else on the J314s. This replaces aurora-silicon/linux#302.