Repository navigation
t6041-j614c-j616c: USB 3 on the USB-C ports - #1476
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>
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.
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. Integration preserves the now-merged1468port graph and1475DP-to-USB3 PHY teardown. Matching Aura147 must also land for the source pair; no old-loader default rollout is approved. The mailbox is removed from the shared max-chain array, and1546 has a corresponding fix candidate so it cannot skip the crossbar. Original ancestry and newer main behavior retained; fresh native/host/DT gates are required before merge.
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
DjDeveloperr
left a comment
There was a problem hiding this comment.
Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.
The source failure was reproduced on the exact CI base290571a: refkey.rs and test_policy_window.py are byte-identical to the failed head67c6c636. The check reads only the text before PREPARE inside a deferred closure and misses the later real-root policy_window(unlock) dispatch. Guarded initrd remains read-only and the write-refusal check remains intact; no production guard change is warranted.
Appended test-only48bf7a41 and opened shared fix #1564. The exception is limited to refkey_unseal_cached: PREPARE must be inside its named closure, the direct invocation must be in the existing keystore_only branch, the real-root invocation must use policy_window, and all closure uses are counted. Existing call-site/Touch ID assertions remain. Seven cases pass normally and with Python -O; mutants removing the real-root wrapper or adding an unguarded call are rejected. Independent review also rejected reversed-condition and out-of-closure cases. All42 production Rust files match the tested integration fixture exactly.
No M4 driver/DT/loader or SEP policy changed. Source approval is retained; fresh host/DT/SEP checks on48bf7a41 and the1472->1473->1476 merge order plus Aura147 pairing remain required. Do not retry the superseded old source failure.
Whitespace only; preserve every assertion and negative control. 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>
bbfc5dd
into
aurora-silicon:integration/aurora
The M4 Max laptops run their three USB-C ports at USB 2 only:
high-speed, with only their USB 2 PHY;That's because the loader had no ATC tunables to give them. aurora-silicon/aura#147 exports them from the ADT on the J614c and J616c, as it already does on the J614s. With that in place, this PR describes the ports the way the M4 Pro does.
arm64: dts: apple: t6041-j614c-j616c: enable USB 3 on the USB-C ports
atcphy1. The loader appends its own, so leaving them would duplicate every entry.soc: apple: display-gate: leave the M4 Max ATC1 mailbox to the PHY
The M4 Max USB-C display chain listed
atcphy1's mailbox among the nodes it enables. With the mailbox on for USB 3, the gate refused to bring up dcpext1:The mailbox belongs to the PHY coprocessor, so this drops it from the chain, as the M4 Pro's chain leaves its ATC mailboxes out. It's also marked enabled in the KUnit fixture.
This builds on #1468, which adds the left-back port. It needs the aura change above: a loader without it leaves these PHYs with no tunables, and the ports don't work. It merges cleanly with #1472 and #1473.
Tested on a J614c (linux-aurora 28.5 with this, #1468, #1472, #1473 and the #1475 PHY fix; aura with the change above):
/dcp@602e00000with the mailbox already on. USB-C DisplayPort works on the left-front port, as does HDMI.Not tested on the J616c.
🤖 Generated with Claude Code