[BTNG-studio]

Summary

The 16" binned M3 Max MacBook Pro (J516M) has the J514M's T6034 die: its ADT names the same DCP image (F493F03E-…), it loads the same 14.7 G15C GPU image, and its chassis and panel are the J516C's. #372 explicitly leaves the J516M out. This PR admits it on the same terms, so its internal display and GPU start by default.

Stacked on #372 (and through it #363). It targets #372's branch, so the diff shows only these three commits.

 drm/apple  iomfb_v14_7.c
   dcp_v14_boards
     T6030, J613, J615, J516C, J514C, J514M
+    J516M: J514M DCP/image/handoff, 3456x2234 with 74 notch rows, ProMotion, panel controls off
 soc/apple  t6030-display-gate.c
-  T6034 native display by default on: J514M
+  T6034 native display by default on: J514M, J516M     (apple_t6034_display.enable=0 still opts out)
 drm/apple  apple_drv.c
+  T6034 GPU link follows the display on the J516M
 drm/asahi  g15
+  T6034 admission: apple,j516m + apple,t6034
+  firmware row "J516M RTKit 2419.140.12": the J514M digest, pinned to apple,j516m
 dts  t6034-j516m.dts
+  t6034-dcp.dtsi, &dcp panel (J516 panel: 346 x 223 mm, 500 nits)

The GPU starts at the same profile as the J514M, including the J516C power/reference words #372 marks as unqualified. Brightness and other panel controls stay off, as on the J514M. External displays are a separate draft (#406).

Paired m1n1 change: omacom/m1n1#28 (stacked on omacom/m1n1#24) gives the J516M the T6034 display and GPU defaults. Ship order: as with #388, m1n1 must not ship before this kernel. A J516M with the new m1n1 and an older kernel gets the handoff but no board record, and stays on the boot framebuffer.

Mesa: no J516M change needed. omacom/mesa#32 admits the 30-core T6034 by its parameters, and this J516M reports exactly that contract (comment on mesa#32 with the evidence).

Evidence

Hardware: my J516M (Mac15,11, MacBook Pro 16" M3 Max, 30-core GPU), OS firmware 14.7, system firmware 27.0, Omarchy with Hyprland 0.56.2.

What ran: these changes on the previous #372 head 19b6f899f, in local builds linux-aurora 7.2.11.aurora14-102 through -108 with m1n1 builds up to m1n1-aurora 1.6.1.aurora22-103 and Mesa with #32's admission patch, on my machine across several boots since 2026-11-06. Rebasing onto #372's current head e585531e0ba6 applied cleanly. The rebased commits are compile-tested but not booted. The only source differences from what booted are comment wording, a variable rename (j514m_board → t6034_board) and the firmware row's name string.

• Display (normal command line, no m1n1 config lines beyond the defaults):

  apple-dcp 386c00000.dcp: J516M display started: 3456x2234@120, 74 notch rows shown, 346x223 mm
  [drm] Initialized apple 1.0.0 for display-subsystem on minor 1
  

• GPU: the loaded firmware's identity matched the J514M row byte for byte (TEXT 0x64000, DATA 0x140000, GKTS 0x5cf28, sha256 4ca24b65…04b7):

  asahi-g15 40a400000.gpu: GPU firmware build: J516M RTKit 2419.140.12 (local port, J514M identity)
  asahi-g15 40a400000.gpu: M3: firmware identity accepted
  asahi-g15 40a400000.gpu: T6034 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0x7b5ed7f5fd
  asahi-g15 40a400000.gpu: T6034 G15C: cores enabled per cluster: [8, 8, 7, 7]
  

  (The name string was shortened to J516M RTKit 2419.140.12 for this PR.) Hyprland renders on renderD128 (asahi-g15) with a high-priority context. No GPU faults in the kernel log across those boots.
• Host tests (tools/aurora-ci/host-tests.py, full manifest, on this branch's head): 159 of 166 pass, plus the manifest's 6 known failures. The one failure is noted below. Updated for the J516M:
  • t6034-display-tests.py admits the J516M, with two new mutants (J516M dropped from the gate default, J516M record lost) that are caught.
  • g15-display-order-tests.py links the J516M GPU, and an unknown T6034 board (apple,j999) stays refused.
  • g15-t6034-profile-tests.py checks both firmware rows, that each board pins only its own row, and that a changed digest is refused on the J516M.
  • On this machine tools/testing/selftests/drivers/gpu/apple-dcp/run.sh fails the same 6 cases on Add guarded J514M/T6034 native graphics bring-up #372's unmodified head (environment), so it says nothing about this change.
• KUnit: a v14_board_j516m case in v14-board-test.c. Not run locally; left to CI.
• Compile: tools/aurora-ci/compile-check.py --per-commit with the shipped config: every commit builds, no new W=1 warnings. The Rust GPU driver, drivers/gpu/drm/apple, drivers/soc/apple and t6034-j516m.dtb were built separately with the package's toolchain (Rust 1.85.0, LLVM 18, W=1). They build, the new firmware row is in the built asahi object, and the only Rust warning in boot.rs is the existing unused params import (line 49).
• Commits: all signed off. checkpatch: one advisory warning, apple,panel-j516 undocumented, the string the J516C/J516S trees already use.
• Not tested: brightness (closed, as on the J514M), sustained GPU load, thermal, suspend/resume on the rebased commits, CTS.

Merge Danger

Door: two-way

Blast Radius: J516M only

Only a root with apple,j516m and apple,t6034 gets the new display record, the display default, the GPU link and the GPU firmware row. The J514M's record and firmware row are unchanged, and neither board's row admits the other. Every other Mac is untouched, and a J516M without the paired m1n1 behaves as today.

🤖 Generated with Claude Code