Repository navigation
thunderbolt: apple: let T6020 DP IN tunnels wait for a display pipeline - #426
Open
nekolyanich wants to merge 1 commit into
Open
nekolyanich wants to merge 1 commit into
nekolyanich wants to merge 1 commit into
Conversation
apple_dpin_m2, the T6020/T6021 (M2 Pro/Max) ACIO policy, leaves
capacity_retry off "pending M2 hardware qualification". A DP IN tunnel
that finds no free display pipeline gets -EBUSY once and that is final
("dpin0: DP tunnel setup failed: -16"). The connection manager keeps
the tunnel through the DPRX timeout (TB_HOST_DP_KEEP_DPRX_TIMEOUT), but
nothing asks for a pipeline again, so the display stays dark.
On a MacBook Pro 16" M2 Pro (j416s) with a monitor on a Thunderbolt
cable and a TV on a USB-C to HDMI adapter (DP Alt Mode), the fabric
moves the TV to dcpext1 at boot and gives the tunnel dcpext0. After a
system resume the TV comes back first on dcpext0 and the tunnel's
request is refused. The fabric moves the TV to the other pipeline
a few seconds later, too late for a request that is not retried.
Set capacity_retry on apple_dpin_m2. A refused tunnel then waits as on
M1: the DP IN work arms its retry and routes the tunnel once a pipeline
comes free. M2 needs no dp_tunnel_awaits_display hook, which is set up
for the APPLE_DPIN_CHANGED flow only: KEEP_DPRX_TIMEOUT already keeps
its tunnels. As on M1, -EAGAIN waits too: an attempt that prepare cut
short returns it and has to ask again after complete. A DCP service
that is never published then waits until unplug, with a 120 s readiness
wait per retry, where it used to fail once.
Pause these retries across system sleep and at NHI removal. The PM gate
(apple_dpin_pause_retries(), apple_dpin_resume_retries(),
apple_dpin_end_pm_gate()) now applies wherever the policy has
capacity_retry or defer_new_bringup, not defer_new_bringup only.
apple_nhi_prepare() pauses the retries of a gated policy without
defer_new_bringup (M2) before its resume_recovery=0 return, so at the
default a waiting M2 tunnel stops asking at prepare; with
resume_recovery set it pauses where M1 does. Either way its pause ends
when complete starts, before tb_domain_complete(): every device has
resumed by then, and the tunnel that the domain's complete brings back
makes its first attempt there, since M2 does not defer it. Its retries
then run from the refusal on, as before, and do not wait for the end of
complete, which can take seconds. M1 and M3 at the default are
unchanged: their pause stays behind resume_recovery (6ceb98a).
Without the gate a waiting M2 tunnel would keep calling into appledrm on
the non-freezable dp_wq while the DCPs power off, and after the NHI is
removed. M2 does not get defer_new_bringup: that would defer every first
M2 handoff across sleep, which has not been tested, and DPRX retention
for a deferred handoff goes through the hook M2 does not install.
apple_dpin_end_pm_gate() now pauses both adapters before it drains
them, as apple_dpin_pause_retries() does: work in flight at NHI removal
could otherwise get -EBUSY and rearm the retry it had just cancelled.
On M1 this is the only change: a bring-up in flight at NHI removal is
deferred and then dropped instead of attaching. Base M2 (T8112) uses
apple_dpin_m1, and M3 is unchanged.
Update the comments above apple_dpin_work_fn() and
apple_dpin_pause_retries(), which named M1-family hosts. Tests: the M2
row of apple_dpin_all_policy_fields; the t602x rearm trace, whose -EBUSY
now waits and recovers; the capacity trace run for M2 as well; terminal
errors end an M2 wait; apple_dpin_m2_capacity_suspend (pause, resume, a
refusal after the pause has ended, resume with no pause, -EAGAIN under
pause, unplug while waiting, end of the gate).
In omacom/linux-aurora, commit 068fd09 ("thunderbolt: apple: let
T6030 DP IN tunnels wait for a display pipeline") restores the same
flag for M3 after the aurora-silicon#139 merge dropped it; M2 never had it.
Testing: j416s, DCP firmware 13.5, under the m1n1 hypervisor,
pm_test=platform, with a bench-only DT change that keeps the
hypervisor's USB-C port out of the DCP routes. Monitor and TV: the
monitor came back after 6 of 6 resumes with this change (0 of 2 without,
on aurora 7.3 ac6b017, same thunderbolt and appledrm code), routed
6.2-6.5 s after the refusal and 3.4-3.8 s ahead of the DPRX timeout; no
DPRX timeout, no kernel WARNINGs. Monitor alone: back after 4 of 4
resumes, no wait. KUnit apple-dpin-lifecycle 35 of 35.
Not tested: natively, a suspend while a tunnel waits (KUnit only),
j414s, j414c, j416c, other firmware, a wait past the DPRX timeout, NHI
removal while waiting.
Assisted-by: Claude:claude-opus-5-5 checkpatch
Signed-off-by: nekolyanich <me@nekolyanich.com>
Contributor
|
The current port is review/pr426-integration-t3094-v3, head bb91b3f. It preserves original authorship and sign-offs, #395's M3 retry/suspend behavior, the M2 capacity trace and terminal-error coverage across all three policies. Earlier public refs and the contributor's branch remain intact. On integration/aurora at 421e314 with shared #438 and #456, DCP is PASS (63/63). KUnit has 906 passes and 1 policy skips. Universal WERROR is PASS; Fedora-base WERROR is PASS. Software gates pass; hardware and shared #438/#456 review pending. The operator reports #456 passed all 63 host groups with stock make 3.81 and GNU Make; this worker did not rerun native macOS on the assembled base. Hardware still needed: J416s capacity retry, suspend, unplug and NHI removal; M1 Pro/Neo regression. |
Author
|
Tested on J416s (M2 Pro),
Runs and this summary were prepared with Claude (Opus 5.5); counts checked against the logs. |
This was referenced Oct 27, 2026
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 T6020/T6021 (M2 Pro/Max)
apple_dpin_m2leavescapacity_retryoff, so a DP IN tunnel that findsno free display pipeline gets -EBUSY once and that is final (
dpin0: DP tunnel setup failed: -16).The CM keeps the tunnel through the DPRX timeout, but nothing asks for a pipeline again, and the
display stays dark.
On a MacBook Pro 16" M2 Pro (j416s) with a Dell on Thunderbolt and a TV on a USB-C to HDMI adapter,
the TV takes dcpext0 first after a system resume and the tunnel is refused; the fabric frees a
pipeline a few seconds later, too late. The Dell came back after 0 of 2 resumes (aurora 7.3
ac6b017, same thunderbolt and appledrm code).
Change
capacity_retry = trueonapple_dpin_m2: a refused tunnel waits and retries as on M1.TB_HOST_DP_KEEP_DPRX_TIMEOUTalready keeps M2 tunnels, so nodp_tunnel_awaits_displayhook.capacity_retrypolicies too. M2 pauses at prepare also at the default
resume_recovery=0, and resumes whencomplete starts, so a tunnel refused inside complete retries on time. M1 at the default is unchanged.
apple_dpin_end_pm_gate()pauses before draining, so work in flight cannot rearm the retry.Base M2 (T8112) and M3 are unchanged. omacom 068fd09 restores the same flag for M3 (T6030);
M2 never had it.
Testing — j416s, DCP 13.5, under the m1n1 hypervisor,
pm_test=platform, with a bench-only DTchange that keeps the hypervisor's USB-C port out of the DCP routes (
t602x-j414-j416.dtsi):3.4–3.8 s ahead of the DPRX timeout; no DPRX timeout, no kernel WARNINGs. DP audio played on both
sinks before the suspend, 16 of 16.
apple-dpin-lifecycle: 35 of 35.Not tested: natively; a suspend while a tunnel waits (KUnit only); j414s, j414c, j416c; other
firmware; a wait past the DPRX timeout; NHI removal while waiting.