Repository navigation
t6041-j575c: USB-C display on typec1, USB3 and the fourth back Type-C port - #1546
DjDeveloperr merged 17 commits into
Conversation
The loader fills the M4 Max's external DCP firmware memory only from the three-region layout the M4 Pro uses: a text, a data and a heap placeholder (t6040-j616s-extdisp-mem-loader.dtsi). It points the text region at the internal DCP's TEXT, which the processors share, and fills the other two from the ADT. The J616c's HDMI and USB-C dcpext nodes describe only data and heap, so on a J614c the loader refuses both processors and the display gate keeps the external displays off: DCP: T6041: dcpext0 firmware memory refused; placeholder remains disabled DCP: T6041: dcpext1 firmware memory refused; placeholder remains disabled apple-t6041-display: /dcp@3a2e00000: no firmware memory, nothing enabled Add the text placeholder to both, as on the M4 Pro. The display gate only needs every region to be available asc-mem. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The M4 Max laptops have external displays but no audio for them: no SIO alias, no dpaudio controllers, and no DPA power domains, which only t6040-pmgr.dtsi describes. Their ADT has the M4 Pro's audio path (J614c read from the running machine): dcpext0's audio is dp-audio1 on SIO DMA channel 0x66 and dcpext1's is dp-audio2 on 0x68, and the PMGR has UART_P (0x1a0) and DPA_P (0x1a8) under SIO and DPA1 (0x238) and DPA2 (0x240) under DPA_P. Describe them as t6040-j616s-dpaudio.dtsi does: the four domains, the SIO alias the loader uses to reserve the SIO firmware and enable the SIO, the two dpaudio controllers and their links to dcpext0 and dcpext1, the SIO CPU domain's parents, and the SIO DART and mailbox. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The M4 Max laptops run their three USB-C ports at USB 2 only: the PHYs carry a hardcoded USB 2 tunable, the controllers are limited to high speed with only their USB 2 PHY, and nothing connects the connectors' SuperSpeed lanes. The left-front port's DisplayPort description adds a hardcoded set of ATC tunables for atcphy1. Their ADT has the M4 Pro's per-port ATC and controller tunables (atc-phy0..2, usb-drd0..2, J614c read from the running machine), which the loader copies into the PHY and controller nodes, as it does on the J614s. Describe the ports as the M4 Pro does: the controllers use both PHYs, the PHYs link to the connectors' SuperSpeed lanes and to the controllers, and the PHY mailboxes are on. Drop the hardcoded tunables, which the loader would otherwise duplicate. The HDMI PHY keeps its own. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The M4 Max USB-C display chain lists atcphy1's mailbox among the nodes it enables, and gives up on dcpext1 when any of them is already on. The mailbox is the PHY coprocessor's, which USB3 needs whatever the display does, so a device tree that runs the port at USB3 enables it and the gate then leaves the USB-C display off: apple-t6041-display: /mailbox@38b148000: already enabled, nothing changed Drop it from the chain, as the M4 Pro's leaves its ATC mailboxes out, and mark it enabled in the test fixture as the device tree does. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The J575c has four back Thunderbolt ports, but the tree only describes ATC0-2. The fourth (ADT port-location back-left) is hpm3 on nub-spmi-a0 at 0x6 with interrupts 89/95/97, atc-phy3, usb-drd3 and dart-usb3. On the J614c/J616c ATC3 is the HDMI converter's fixed DP PHY, so there is no shared USB description of it; here it is a USB-C port like the other three. Add its PHY, PHY mailbox, DARTs and controller as t604x.dtsi has them for ATC2, at the ADT's ATC3 addresses (ATC2's plus 0x8000000) and interrupts (the controller and DART ones ATC2's plus 32, the PHY coprocessor's plus 10), the controller's usb-drd3 tables (the same as usb-drd0-2), and hpm3 with its connector. t604x-pmgr.dtsi leaves the ATC3 domains disabled for the J616c's display gate, so they are enabled here. Tested on a J575c: the port's PD controller, PHY and controller come up, and a USB hub and a USB stick behind it enumerate. Before, the port had power but no data. Assisted-by: LLM Signed-off-by: Roberto Dantas <7robertodantas@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The back Type-C ports run at USB2 only. Describe USB3 on all four as t6040-j616s-usb3.dtsi does on the J616s: each PHY's tunables, the pipehandler table, the PHY coprocessor mailbox, the SuperSpeed endpoints between connector, PHY and controller, and the controller's USB3 tables with both PHYs. The values come from this machine's ADT (macOS 27.0.1): atc-phyN for the PHY tables and usb-drdN for the controller and pipehandler ones, converted as aura's kboot_atc.c does. The controller and pipehandler tables match the J616s's on all four ports; the PHYs differ in their per-port calibration (axi2af, aus40cmn-shm, and auspll on ATC2). Tested on a J575c (with the fourth port from the previous commit): - a USB 3.2 Gen 2 SSD at 10 Gb/s (uas) on ATC2; - a USB 3.2 Gen 1 stick behind a hub at 5 Gb/s (uas, 128 MB/s read) on ATC1 and ATC3; - the debug USB link on ATC0 keeps working. Not every connection trains at SuperSpeed yet: some devices only do in one plug orientation, and a device attached at boot sometimes stays at USB2 until it is plugged in again. Both fall back to USB2, as before. The board has Type-C retimers (ADT i2c6 uatcrt0..3), which have no driver yet, as on the J614/J616. Assisted-by: LLM Signed-off-by: Roberto Dantas <7robertodantas@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… ATC mailbox The M4 Max external-display stages are the J616c's. Its typec1 chain starts with the ATC1 PHY's coprocessor mailbox, which the J616c's tree leaves disabled because that port has no USB3 there. The J575c's typec1 is also a USB3 port, so its tree enables that mailbox, as the M4 Pro boards do, and the stage would then refuse the whole chain as "already enabled". On the J575c, use the same chain without the mailbox. Nothing changes on the J614c and J616c. Tested on a J575c with the next commit: the gate enables dcp@602e00000's chain, and a monitor on typec1 (USB-C to HDMI adapter, pin assignment D) shows the console. Assisted-by: LLM Signed-off-by: Roberto Dantas <7robertodantas@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The J575c has no display output: iBoot lights neither HDMI nor a USB-C display, and leaves a 640x1136 dummy framebuffer. It does leave the external display processors powered with their firmware loaded (DISPEXT0-3 SYS/FE on, CPU hardware-gated, iop-dcpextN-nub segments present), as on the J616c, but there is no panel and no internal display handoff to enable the display subsystem. Describe the J616c's typec1 chain (dcpext1, the ATC1 crossbar and atcphy1 in DP alt mode, driven by hpm1) for the J575c's typec1, the back port next to the one at the right edge, with the firmware memory placeholders of t6040-j616s-extdisp-mem-loader.dtsi (text, data, heap), and the dcp/disp0 aliases the boot loader's handoff looks for. A boot loader that knows the J575c fills dcpext1's memory and enables the display subsystem; the display gate then enables the chain. Without one, the display stays off as before and the port keeps working as USB. ATC3 is the fourth back Type-C port, not the J616c's HDMI PHY, so t604x-extdisp.dtsi's ATC3 description is replaced by the port's own. Tested on a J575c with the aura J575c handoff: a USB-C to HDMI adapter (pin assignment D, two DP lanes beside USB3) on typec1 drives a 2560x1440 monitor with the Linux console from a cold boot and after a replug. With aura 1.0.0b8 (no J575c handoff) the gate logs "display subsystem not enabled" and nothing else changes. Not described yet: HDMI, which runs through the lpdptx PHY that has no T604x driver. Assisted-by: LLM Signed-off-by: Roberto Dantas <7robertodantas@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Preserve original contributor commits and dependency-ordered M4 changes.
Preserve original contributor commits and dependency-ordered M4 changes.
Preserve original contributor commits and dependency-ordered M4 changes.
Preserve original contributor commits and dependency-ordered M4 changes. Use the full mailbox-free common display chain after PR1476, retaining its crossbar.
DjDeveloperr
left a comment
DjDeveloperr
left a comment
There was a problem hiding this comment.
Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.
P1 cross-PR integration gate: the J575c stage uses t6041_max_usbc_nodes+1 /size-1 to skip a mailbox, but1476 removes that first mailbox from the SHARED array. Both unchanged would skip the crossbar instead. I am fixing this on the contributor branch against an explicit1476 integration parent, preserving all newer main logic; merge order must place1476 first. Matching Aura160 and current CI remain required. Posted typec1 display/selected-port USB3 results do not qualify the other external ports/HDMI or known orientation/boot-attached fallback. Do not publish blanket Working from this PR alone.
DjDeveloperr
left a comment
DjDeveloperr
left a comment
There was a problem hiding this comment.
Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.
No remaining blocking source findings in the reviewed/integrated net change. The P1 integration hazard from my prior review is fixed on this head: it contains the explicit1476 integration parent and uses the full now-mailbox-free shared chain instead of nodes+1/size-1. The crossbar is no longer skipped. All695 reviewed hexadecimal calibration triples fit their masks; the board-scoped graph retains other M4 behavior. Merge1472->1473->1476 before this PR, and land matching Aura160 as the source pair. New contributor CI approvals are required again for this head and are being unblocked. Known limited-port/orientation/boot-attached and HDMI coverage remains explicit; this does not approve default loader deployment.
Approval does not waive pending CI, dependency order, hardware-safety gates or source-versus-release qualification. No source merge is an installed-loader write or a new hardware test.
Backport the test-only correction from aurora-silicon#1564. The cached ref-key unlock closure is dispatched through the real-root policy window after its definition. Validate that complete dispatch and reject unwrapped or extra invocation; retain call-site inventory and initrd rules. No production SEP, keybag or guard-policy changes. Assisted-by: LLM
Carry the test-only correction from linux#1564 and updated prerequisite linux#1476. The deferred unlock closure is validated at its real-root policy-window dispatch, with unsafe-call negative controls. Production J575c/M4 display-gate, DT and SEP/guard code remain unchanged. Assisted-by: LLM
DjDeveloperr
left a comment
DjDeveloperr
left a comment
There was a problem hiding this comment.
Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.
The source job reached the same inherited test_policy_window false positive already repaired in #1564 and the updated #1476 prerequisite: it scans text before a deferred unlock closure's call and misses the later real-root policy_window dispatch. This is not a J575c display-gate or production SEP failure.
Merged the updated prerequisite48bf7a41 into this branch as c6f7213, retaining original4d22a6df as first parent. The only incremental file change is the identical test fix (blob d226e1d0); all42 production Rust files exactly match the fixture that passed seven cases normally and with Python-O, plus independent unsafe-call mutation checks. Production gate/DT/SEP code, including the full mailbox-free shared array that preserves the crossbar after1476, is unchanged.
Source approval is retained; fresh current-head host/DT/SEP CI and the1472->1473->1476->1546 merge order with matching Aura160 remain required. Existing typec1/orientation/boot-attached USB3 qualification limits still apply. Do not retry superseded4d22a6df source or host jobs.
Whitespace only; preserve every assertion and negative control. Assisted-by: LLM
Only remove the extra EOF blank; no production or assertion change. Keep the updated USB3 prerequisite in this branch's ancestry. Assisted-by: LLM
Use the exact upstream test from ea10c4d; supersede the duplicate local repair. Production source is unchanged. Signed-off-by: Diljit Singh <hey@djdev.me>
2674439
into
aurora-silicon:integration/aurora
Written with an AI assistant (Claude) on @7robertodantas's behalf; every hardware step was run and checked on the owner's J575c.
The J575c (Mac Studio M4 Max) gets a display, USB3 and its fourth back port. Test report: #1498. The display also needs aurora-silicon/aura#160 (the J575c handoff); without it nothing changes for the display, and the USB parts work on their own.
1. The fourth back Type-C port. The tree had ATC0-2 only. The ADT has hpm3 (nub-spmi-a0 0x6, IRQs 89/95/97), atc-phy3, usb-drd3 and dart-usb3, all at ATC2's addresses plus 0x8000000.
t6041-j575c-atc3.dtsiadds them as t604x.dtsi has ATC2, and enables the ATC3 power domains that t604x-pmgr.dtsi keeps off for the J616c's gate. Before: power, no data. After: the port enumerates (a hub and a stick behind it).2. USB3 on the four back ports, as on the J616s, with each port's own atc-phyN / usb-drdN tables from this machine's ADT. The controller and pipehandler tables equal the J616s's; the PHY calibration differs per port. Measured: a USB 3.2 Gen 2 SSD at 10 Gb/s (uas) on ATC2; a Gen 1 stick at 5 Gb/s (uas, 128 MB/s read) on ATC1 and ATC3; the debug USB link on ATC0 still works.
Known limitation, not a regression: some devices only reach SuperSpeed in one plug orientation (the same SSD and cable: lane 0 stays at 480M, lane 1 trains Gen 2), and a device attached at boot sometimes stays at USB2 until it is plugged in again. Both fall back to USB2, as every port did before. The board has Type-C retimers (ADT i2c6 uatcrt0..3) with no driver yet, as the J614/J616 tree notes for its own.
3. Display gate. The J616c's typec1 stage starts with the ATC1 PHY mailbox, which its tree leaves off (no USB3 there). The J575c enables it for USB3, so the stage would refuse the chain. On the J575c the same stage runs without that node; nothing changes elsewhere.
4. USB-C DisplayPort on typec1. iBoot lights no display on the J575c (dummy 640x1136 framebuffer, also with a USB-C display connected), but it leaves DISPEXT0-3 powered and their firmware loaded (read from aura's KIS proxy: SYS/FE
0xff, CPU0x1000030f, segment ranges present). The J616c's typec1 chain is described for the J575c's typec1 (back port 2 from the right edge), with the text/data/heap placeholders of t6040-j616s-extdisp-mem-loader.dtsi and the dcp/disp0 aliases. t604x-extdisp.dtsi's ATC3 (the J616c's HDMI PHY) is replaced by the real port from (1).With the aura handoff, from a cold boot and after a replug, a USB-C to HDMI adapter (pin assignment D, two lanes beside USB3) drives a 2560x1440 monitor with the console:
With aura 1.0.0b8 and this tree, the gate logs
display subsystem not enabled, external displays left off, and all four ports still work.Checks: dt-validate (dtschema 2026.9) on the J575c DTB: 0 warnings at the base and at the head. Tested with integration/aurora 1943af8 plus these commits as a linux-aurora package build (the gate patch is the same as here); the device tree was compared with the PR's: only #1499's DockChannel/hub nodes and the newer upstream microphone
iommusdiffer.Not done yet: display on the other three back ports (dcpext0/2/3 are powered and loaded too), and HDMI (lpdptx PHY, no T604x driver).
🤖 Generated with Claude Code