[digital-brew]

Problem. On the 16-inch M3 Max MacBook Pro (J516C, T6031) no external display works: the USB-C ports never get a display pipeline, and the HDMI port has no connector at all. The T6030 (M3 Pro) external display support does not reach T6031: its four dcpext processors and the ATC display crossbars are not described, several T6030 paths check apple,t6030 alone, and the J516C tree describes only ATC0..2, not the ATC3 PHY behind the HDMI port.

Fix. Bring T6031 onto the T6030 external display path, then describe the J516C HDMI port.

Patches

1. arm64: dts: apple: t6031: describe dcpext0..3 and the ATC display crossbars.
2. soc: apple: display-gate: hand over T6031 external display processors. Opt-in, behind apple_t6031_display.dcpext=1.
3. drm: apple: run T6031 external processors on the J516C 14.7 image.
4. arm64: dts: apple: t6031: link each dcpext to its PMP DISPEXT request.
5. drm: apple: find the T6031 display subsystem for a native dcpext.
6. drm: apple: check the T6031 dcpext floor on its own dispext<N>_fe.
7. apple: put the T6031 dcpext power floor on its CPU domain. A T6031 dispext<N>_fe state does not hold the PMGR minimum-state field.
8. drm: apple: take a T6031 dcpext timing's colors from ColorElements. The J516C 14.7 firmware publishes every external timing with an empty ColorModes array, so every mode was rejected.
9. drm: apple: clock the T6031 crossbar's direct DP output on link config. Without it every mode set failed with IOAVVideoInterface prepareLink() failed.
10. apple: run Thunderbolt DP tunnels on T6031. The T6030 source map is assumed to hold on T6031.
11. thunderbolt: keep T6031 DP tunnels out of bandwidth allocation mode. With allocation mode on, the tunnel reported 0 Mb/s consumed and the sink dropped the stream after about 1.5 s.
12. arm64: dts: apple: j516c: describe the HDMI port. From the J516C ADT: ATC3 and its crossbar at the T6030 addresses, the J514S/J516S SMC power pins, and HPD on AOP GPIO 42 (47 on the J514S/J516S). dcpext0 takes the fixed route as a hybrid pipeline. The atcphy3 alias lets m1n1 copy the ATC3 calibration.
13. arm64: dts: apple: j516c: keep dcpext1..3 from the display gate. Stopgap, see below.
14. drm: apple: rebuild a T6031 dcpext catalog when its colors change. Review follow-up to patch 8: the catalog is rebuilt on either publication order, replacement and withdrawal, and the shared-colors fallback is T6031-only.
15. drm: apple: wait for a dcpext display's timings before its first swap. Fixes the first-mode failure described below.

Depends on m1n1. The handoff comes from an m1n1 change that is not in this PR: kboot_display_handoff: hand off the T6031 external display processors, on omacom/m1n1 bc79acc4, armed by chosen.asahi,t6031-dispext=1: omacom/m1n1#21.

Why patch 13. On this J516C only dcpext0 brings up a display. dcpext1..3 time out in the DPTX remote port, on USB-C and, for dcpext3, on the HDMI route too:

AppleDCPDPTXRemotePort (chan:1) command type 0xc0 tag 0x0300 timed out after 1000 ms
dcp_dptx_connect: failed to assert Type-C HPD: -110
DPTXPort: firmware reports link fault 22 on target 0:3

With HDMI on dcpext0, the allocator offers a hybrid pipeline to USB-C last (dcp_fabric_score), so every USB-C display landed on a broken processor. Marking dcpext1..3 "fail" keeps them from the gate, and the DRM device waits only for available processors. This limits the J516C to one external display until dcpext1..3 are understood. I have not found why they fail.

Testing (J516C, iBoot 10151.140.19.700.2, OS firmware 14.7, system firmware reported as unknown; m1n1 bc79acc4 + the handoff change; boot with apple_t6031_display.dcpext=1; Hyprland):

• Base: tested on integration 3bdf11d3 (aurora11) + this series. Rebased onto 12be0475 without conflicts; not re-run on that base.
• USB-C, directly and through a USB4 dock: pass. A 4K-class DSC monitor at 60 Hz, and at 120 Hz with DSC on (firmware: DSC=YES). All three ports passed with patches 1–11; with patches 12–13, one port was re-run.
• HDMI: pass, same monitor and modes.
• Moving the display from USB-C to HDMI without a reboot: pass. dcpext0 releases the Type-C route and takes the fixed route.
• Coldplug and hotplug, USB-C and HDMI: pass.
• No DPTX timeouts, link faults or flip failures on dcpext0 in these runs.
• Not tested: two external displays (not possible with patch 13), the 14-inch J514C, system sleep with an external display, HDMI audio (not described yet).
• KUnit (arm64, qemu): 114/114 pass, including the new dcp_v14_shared_colors (patch 14) and dcp_v14_normal_mode (patch 15) suites, under W=1 and PROVE_LOCKING.

First-mode failure, fixed by patch 15. When an external display's first mode on a new connection was a DSC one (3840x2560@60), the first swap was dropped and the processor stopped until reboot:

IOMFB: swap_submit_dcp: swallowed swap ID 1 as timinsg are not enabled for External Display
DCP call 0x41343037 failed: -110; recovery requires a reboot
native DCP flip failed -110; buffers pinned until reboot

Cause: after A472(1) the firmware starts the display's timings in a deferred run mode change, then sets the boolean property NormalModeActive (D104) to 1. With a slow first mode (2560x1600@60) that change ends inside A472; with the DSC mode it ends about 20 ms after A472 replied, and a swap sent in that gap is dropped. Later swaps sent early are held rather than dropped, which is why only a session's first mode failed. With dynamic debug on the callbacks:

8.597  A472(1)
8.599  D104 NormalModeActive = 0
8.613  A472 replied; A406, A407 sent
8.614  swallowed swap ID 1 as timings are not enabled
8.633  switch to normal mode succeeded; D104 NormalModeActive = 1

Patch 15 waits after every power-on, under the RPC lock, until NormalModeActive is 1 (handling queued callbacks as dcp_v14_idle() does, 500 ms limit, no wait if the firmware never reported it). On the J516C through a USB-C dock with the 3840x2560 display, tested on the aurora11 base with patches 1–11 + 15: six boots (reboot, power cycle, hotplug after login) each set 3840x2560@60 first and completed its first swap in about 18 ms; 20 mode sets in all, 8 at 120 Hz with DSC, all succeeded. The wait took 10–21 ms. Without it, 5 of 5 boots lost the session.

Related: #61 (M3 Max bring-up), #289 (G15 firmware pin on the J516C, needed for the GPU on this Mac; separate change).

🤖 Generated with Claude Code

[chriskearney]

On exact head 26ea9ca83c9cf6050ee9990b08cb662f6b753471, the new shared-color fallback introduces a dependency that the publication callback does not rebuild. dcp_v14_external_published() calls dcp_modes_replace() only for TimingElements. A later ColorElements publication updates the description bits/generation and clears mode_live, but does not reparse the retained timings.

A bounded CPU witness using the exact callback confirms: timings with no local colors first produce zero modes; publishing valid shared colors afterward still produces zero modes; republishing timings then produces the mode. Replacing shared color ID 7 with 11 leaves the catalog selecting 7 until timings are republished. The mode-live guard protects existing swap admission; this is a catalog dependency/order issue, not a demonstrated UAF or hardware reproduction. The fallback also applies to existing native v14.7 external displays, beyond the T6031 opt-in.

Please rebuild or invalidate dependent catalogs for either publication order, replacement and withdrawal, with serialized timing/color parser-publication tests and generation transitions. Alternatively, establish and enforce a protocol ordering invariant that makes these sequences impossible. Waiting longer in external_settle does not rebuild the catalog.

Separately, the documented first-high-bandwidth modeset failure and the unpublished local m1n1 external-handoff dependency remain qualification limits. This source finding can be closed without new hardware access; CI/QEMU would not establish external-display qualification.

[digital-brew]

The m1n1 side is up: omacom/m1n1#21 (kboot_display_handoff: hand off the T6031 external display processors). It is the source this series was tested with, plus a test update for the per-SoC table.

[digital-brew]

Thanks for the review. The catalog dependency is addressed in f401690 ("drm: apple: rebuild a T6031 dcpext catalog when its colors change").

Rebuild on either publication. dcp_v14_external_published() now builds the catalog through one helper, dcp_v14_external_catalog(), from the retained TimingElements and the ColorElements published at that moment. On a shared-colors processor it runs on a TimingElements publication and also on every ColorElements publication, replacement and withdrawal, as long as timings are retained. Your witness sequences now behave as follows:

• timings without local colors first, then shared colors: the colors publication rebuilds the catalog and the mode appears without republishing the timings;
• shared color 7 replaced by 11: the catalog selects 11 straight away;
• shared colors withdrawn, or replaced by colors the timings exclude: the old catalog is withdrawn rather than kept. A new dcp_modes_withdraw() clears admission under modes_lock (the array stays allocated for snapshot readers, as with replacement), DESC_TIMING is cleared so external_settle() waits again, and the display is reported withdrawn.

Generations. A ColorElements transfer rebuilds with its own transfer generation, so one begun before the current attachment is still refused with -ESTALE and neither publishes nor withdraws anything. A removal has no transfer and uses the current generation. The description generation bump and the mode_live clear for color changes are unchanged.

Withdrawal reported once. On hardware the firmware withdraws ColorElements before TimingElements on an unplug (kernel log: ColorElements withdrawn, then TimingElements withdrawn). Reporting both would make the second iomfb_v14_7_external_withdrawn() call release a connector that dcp_v14_external_hold() kept connected. A colors_withdrew flag makes the TimingElements removal skip the report when the color withdrawal already made it. The flag clears on the next catalog that parses.

Scope. The fallback is now opt-in per processor: shared_colors is set only for apple,t6031-dcpext. Other native v14.7 external processors never receive ctx.shared_colors, and their publication path is the same as before this series.

Tests. New suite dcp_v14_shared_colors (iomfb_v14_7_shared_colors_test.c, included from iomfb_v14_7.c so the production callback and raw-property store run; only iomfb_v14_7_external_withdrawn() is a static stub, to count reports). It serializes the publications and checks the catalog, the description and the generations after each step:

• colors then timings, and timings then colors;
• replacement 7 → 11 with no timing republication (mode_live cleared, description generation advanced);
• an UnsafeColorElementIDs exclusion in shared colors, and a replacement that leaves only the excluded ID (catalog withdrawn);
• colors withdrawn before timings and timings withdrawn before colors, each reported exactly once;
• withdrawal followed by republication;
• a ColorElements transfer begun before a new attachment (stale, no publish, no withdrawal), then a current one;
• a processor without the opt-in.

arm64 KUnit under qemu: 106/106 pass (the Apple display and parser suites). With the rebuild on a color publication disabled, 6 of the 8 new cases fail; the two that still pass are colors-first and no-opt-in, which the previous code already handled.

Still open, as you noted: the first high-bandwidth modeset failure, and the m1n1 external handoff dependency (omacom/m1n1#21, awaiting review). Neither is changed by this commit.

[digital-brew]

The first high-bandwidth modeset limit is addressed in 8f6ea2e ("drm: apple: wait for a dcpext display's timings before its first swap"). As you suggested, the driver no longer swaps before the link timings are enabled; the firmware reports exactly when that is.

Cause. After A472(1) the firmware starts the display's timings in a deferred run mode change and then sets the boolean property NormalModeActive (D104) to 1. A472(1) sets it to 0 first. With 2560x1600@60 the change ends inside A472. With 3840x2560@60 (DSC) it ends about 20 ms after A472 replied, and swap ID 1, sent in that gap, is dropped (swallowed swap ID 1 as timings are not enabled), so its A407 never completes. Swaps sent early later in a session are held instead of dropped, which is why only a session's first mode failed. Logged with dynamic debug on the link callbacks and the property names:

8.597  A472(1)
8.599  D104 NormalModeActive = 0
8.613  A472 replied; A406, A407 sent
8.614  swallowed swap ID 1 as timings are not enabled
8.633  switch to normal mode succeeded; D104 NormalModeActive = 1

Fix. dcp_v14_external_wait_normal() runs after every successful A472(1), still under the RPC lock, and waits for NormalModeActive (service 0, not the IOMF service's copy set through D415) to be 1. While it waits it handles the queued callbacks through dcp_v14_link_pump(), as dcp_v14_idle() does. Edge cases:

• Timeout: after 500 ms the mode set fails into the existing retry path rather than leaving a swap to hang.
• A failed callback stops the session, as in the idle worker.
• Firmware that never reported the property is not waited for.

Hardware. J516C, 3840x2560 display through a USB-C dock, aurora11 base with patches 1–11 plus this one, no bring-up workaround:

• 6 boots (reboot, power cycle, hotplug after login), each setting 3840x2560@60 first. The first swap completed in 16.8–17.8 ms every time.
• 20 mode sets in all, 8 of them 3840x2560@120 with DSC. All succeeded.
• The wait took 10–21 ms.
• Without the wait, 5 of 5 boots lost the session.

Tests. New dcp_v14_normal_mode suite. It runs the wait and the production D104 handler with a scripted link pump, covering: not reported, already running, deferred, every power-on, other service, timeout, callback failure and failed session. arm64 KUnit: 114/114 pass, under W=1 and PROVE_LOCKING.

The m1n1 dependency remains, in omacom/m1n1#21. The PR description is updated accordingly.