[DanielLemky]

Depends on #292, #258 and #261; companion loader: omacom/m1n1#41, which carries omacom/m1n1#21 and #24 (#24 was originally stacked on #23, replaced by merged #31). Merged kernel foundations: #363 and #408 (carrying/replacing #372). Target: integration/aurora.
Runtime tested with local Mesa packages based on omacom/mesa#32.

Add the 16-inch J516M M3 Max (14 CPU / 30 GPU cores) to the native display and G15C GPU path. Admit its pinned DCP image, 3456x2234 internal panel, HDMI dcpext0 route, measured GPU firmware digest and fused identity 0x7b5ed7f5fd. Extend the existing PMP GFX bandwidth request to this exact board/SoC pair and use this board's T6034 display opt-out in the PMP startup-failure diagnostic.

Reuse the shared six-channel T6034 layout while preserving J514M's independent profile and supplier. Keep J516M's established T6031 display/PMP metadata namespace, explicit display opt-ins, full firmware checks and existing 120 Hz swap timestamp mechanism. Includes the endpoint-definition include needed to build the combined dependency stack's J514M DTB. Built-in brightness is a separate follow-up: #416.

Validation: main and brightness-follow-up Image/modules/DTBs builds passed. Seven existing host suites passed, including PMP graph/supplier controls and mutants with ASan/UBSan. Independent read-only reviews found no actionable findings. Existing host fixtures are adapted for J516M. The later recovery-diagnostic correction adds no test cases; that exact failure branch was verified statically.

The signed source tree is identical to the tested tree. The combined stack, including the separate brightness follow-up and corrected companion loader, passed native OpenGL/Vulkan pixel checks, matching loaded module build IDs, native compositor, PMP bandwidth request, internal 3456x2234 at 120 Hz, direct HDMI BenQ 2560x1440 at 59.951 Hz, and visible brightness/playback/pointer checks. An earlier small focus-change hitch was not quantitatively retested. USB-C, repeated hotplug, suspend/resume, other GPU bins and sustained power/thermal behavior remain unqualified.

This draft includes the open dependency stack; rebase as those PRs merge so the diff reduces to the J516M commits. Firmware/raw ADT binaries, local boot-image packaging and app-specific playback settings are excluded.

Assisted-by: Codex:GPT-6

[hungbenjamin402]

Second J516M: 120 Hz display, DPMS and suspend pass; G15C needed a second fused-core mask

I tested #416 (which carries #415) with omacom/m1n1#41 on a second J516M. The internal panel runs natively at a measured 120 Hz and survives DPMS and s2idle cycles. G15C refused this die's fused-core mask, then admitted and rendered after a one-line change to hw/j516m.rs (patch below).

Mac and installed build

• Model / board / SoC: MacBook Pro 16-inch, M3 Max, Nov 2023 (Mac15,11) / apple,j516m / apple,t6034
• CPU / GPU / RAM: 14 CPU cores, 30 GPU cores, 36 GB
• Installed via the Omarchy 4.5.0-3 installer. These packages were built locally from the PR heads and installed with pacman -U:
  • kernel: drm/apple: enable J516M built-in panel brightness #416 head e9e02dc5e057, as a side-by-side package linux-aurora-j516m 7.2.11.aurora15-1.900, uname -r 7.2.11-15-1.900-ARCH
  • m1n1: kboot: add opt-in J516M/T6034 display and G15C handoff m1n1#41 head b05e6acd40ec, as m1n1-aurora 1.6.1.aurora22-1.900
  • Mesa: omacom/mesa b7b03c5b3b8a (the merge of J516S AOP: early firmware crash leaves ambient-light sensors absent #33), as mesa-aurora / vulkan-aurora …-1.900
• hyprland 0.56.2-7, aquamarine 0.15.1-1.3
• /etc/m1n1.conf: chosen.asahi,t6034-dcp=1, chosen.asahi,t6034-gpu=1
• Kernel command line: apple_t6034_display.enable=1 added

Both firmware versions and provisioning

• asahi,os-fw-version: 14.7
• asahi,system-fw-version: unknown
• iBoot1 mBoot-20457.40.150.0.1, iBoot2 iBoot-10151.140.19.700.2
• m1n1 stage 1 v1.6.1-dirty, stage 2 b05e6acd-dirty
• Provisioning: not relevant to these results.

Actions and results

Feature / action	Result	Details
Boot with the new m1n1 and display opt-in, but no kernel opt-in	as designed	native display not requested (apple_t6034_display.enable=1 is not on the command line); the display stays on simpledrm. The kernel opt-in is easy to miss for testers.
Native internal display	pass	J516M display started: 3456x2234@120, 74 notch rows shown, 346x223 mm; Hyprland drives eDP-1 at 3456x2234@120
120 Hz flip cadence	pass	DRM page-flip test from a VT with the compositor on another VT, 600 flips on two dumb buffers: avg 8.333 ms (120.00 Hz), min 8.276, max 8.402. 590 of 590 intervals near 8.33 ms, none near 16.67 ms, so no #31-style halving.
Built-in panel brightness (#416)	pass	/sys/class/backlight/apple-panel-bl, max 500. The brightness keys visibly dim and brighten the panel, and the DCP logs each step, e.g. brightness_changed: brightness value: 2621440 … 9175040 (40 to 140 nits in 25-nit steps). Current reading is 350/500. Full range and photometric accuracy not measured.
G15C with #416 as-is	fail	T6034 G15C: power acknowledged, version=0x7041100 counts=0x21040a core-mask=0x73df57f5fd, then J516M powered identity differs from the measured bin, probe ... failed with error -71. The desktop stays on llvmpipe at about 400–500 % CPU.
G15C with the patch below	pass	T6034 G15C admitted, cores enabled per cluster: [8, 8, 7, 7], firmware J516M RTKit 2419.140.12 accepted and READY, /dev/dri/renderD128 present
OpenGL / Vulkan	pass	GL 4.6 (Core Profile) Mesa 26.3.0-devel (git-b7b03c5b3b), renderer Apple M3 Max (G15C B1); Vulkan 1.4.363 Apple M3 Max (G15C B1) (Borealis). Hyprland runs on the render node at about 3 % CPU. No GPU or DART faults logged.
Panel off/on (DPMS)	pass, 10/10	hl.dsp.dpms disable for 3 s, then enable, 10 times. Each cycle reads dpmsStatus 0 then 1 and comes back at 3456x2234@120. No DCP, RTKit, DART or GPU messages in the kernel log during the run.
s2idle suspend/resume	pass, 3/3	systemctl suspend, woken by a key press after about 10 s each time (no RTC wake alarm on macsmc-rtc). After each resume: eDP-1 at 3456x2234@120, renderD128 present, GL renderer still Apple M3 Max (G15C B1), and the backlight unchanged at 350/500. The only kernel errors are from an attached USB storage device (sd/ses) and brcmfmac join_pref -52.
USB-C to HDMI cable (LG 4K60)	fail, expected	The Type-C partner is detected, but no DisplayPort alt mode is entered and no DRM connector appears. Only dcpext0 (the HDMI route) is wired in this stack. dcpext1–3 are status = "fail" and skipped by the gate. Out of scope here; this is the #406 path.
Stock linux-aurora 7.2.11.aurora14-1 booted on the same boot.bin	pass	It ignores the handoff and stays on simpledrm, so the side-by-side fallback is safe.

Not tested yet: the built-in HDMI port (dcpext0 with apple_t6034_display.dcpext=1), lid-close and long sleeps, sustained GPU load, and power and thermals.

Fused-core mask

	version	counts	core mask	clusters (10 bits each, cluster 0 first)
measured bin in hw/j516m.rs	0x07041100	0x0021040a	0x7b5ed7f5fd	0x1fd 0x1fd 0x1ed 0x1ed (8/8/7/7)
this J516M	0x07041100	0x0021040a	0x73df57f5fd	0x1fd 0x1fd 0x1f5 0x1cf (8/8/7/7)

m1n1 reports the same value in /chosen/asahi,t6034-gpu-powered-identity (core-mask-1:0 = 0x73:0xdf57f5fd), and Mesa #33 already admits any 30-core 4×10 layout. So the kernel's exact-mask check is the only blocker.

Proposed change

The patch keeps the exact-identity policy and lists both measured masks. Version and counts stay pinned, and other masks, including the J514M's 0x7b5fc7f5fd, are still refused. The host test gains three cases: the new mask is admitted, and it is refused with a wrong version or with one core removed. tools/asahi/g15-t6034-profile-tests.py passes on Rust 1.93.1. With the new assertions and the old j516m.rs, it fails at the new-mask assertion, as expected.

The commit is on top of #416's head, signed off, in hungbenjamin402/linux-aurora@j516m-second-core-mask:

git fetch https://github.com/hungbenjamin402/linux-aurora.git j516m-second-core-mask
git cherry-pick a15193148e77fff39b214cb4e766cb48f39a08e3

Patch (on e9e02dc5e057)

diff --git a/drivers/gpu/drm/asahi/g15/hw/j516m.rs b/drivers/gpu/drm/asahi/g15/hw/j516m.rs
index 642abbd0999c..08471d7f0b19 100644
--- a/drivers/gpu/drm/asahi/g15/hw/j516m.rs
+++ b/drivers/gpu/drm/asahi/g15/hw/j516m.rs
@@ -25,6 +25,13 @@
     ..super::t6034::CONFIG
 };
 
+/// Fused-core masks measured on J516M boards. Each enables 30 cores, split 8/8/7/7
+/// across the four ten-slot clusters; which slot is fused off differs per die.
+const MEASURED_CORE_MASKS: [u64; 2] = [
+    0x7b5ed7f5fd, // [0x1fd, 0x1fd, 0x1ed, 0x1ed]
+    0x73df57f5fd, // [0x1fd, 0x1fd, 0x1f5, 0x1cf]
+];
+
 pub(crate) fn identity_matches(version: u32, counts: u32, cores: u64) -> bool {
-    version == 0x07041100 && counts == 0x0021040a && cores == 0x7b5ed7f5fd
+    version == 0x07041100 && counts == 0x0021040a && MEASURED_CORE_MASKS.contains(&cores)
 }
diff --git a/tools/asahi/g15-t6034-profile-tests.py b/tools/asahi/g15-t6034-profile-tests.py
index 90605f84d124..d7a6a7d17660 100644
--- a/tools/asahi/g15-t6034-profile-tests.py
+++ b/tools/asahi/g15-t6034-profile-tests.py
@@ -163,7 +163,7 @@ j516m_source = j516m_source.replace('apple,j514m', 'apple,j516m')
 j516m_source = j516m_source.replace('b"apple,j516m",b"apple,j514s"', 'b"apple,j514m",b"apple,j514s"')
 j516m_source = j516m_source.replace('0x7b5fc7f5fd', '0x7b5ed7f5fd')
 j516m_source = j516m_source.replace('[0x1fd,0x1fd,0x1fc,0x1ed]', '[0x1fd,0x1fd,0x1ed,0x1ed]')
-j516m_source = j516m_source.replace(' assert_eq!((c.hw_ids', ' assert!(j516m::identity_matches(0x07041100,0x0021040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041200,0x0021040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041100,0x0001040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041100,0x0021040a,0x7b5fc7f5fd));\n' + ' assert_eq!((c.hw_ids', 1)
+j516m_source = j516m_source.replace(' assert_eq!((c.hw_ids', ' assert!(j516m::identity_matches(0x07041100,0x0021040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041200,0x0021040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041100,0x0001040a,0x7b5ed7f5fd));\n assert!(!j516m::identity_matches(0x07041100,0x0021040a,0x7b5fc7f5fd));\n assert!(j516m::identity_matches(0x07041100,0x0021040a,0x73df57f5fd));\n assert!(!j516m::identity_matches(0x07041200,0x0021040a,0x73df57f5fd));\n assert!(!j516m::identity_matches(0x07041100,0x0021040a,0x73df57f5fc));\n' + ' assert_eq!((c.hw_ids', 1)
 with tempfile.TemporaryDirectory(prefix='t6034-profile-') as temp:
  for name,code in [('profile-j514m',source),('profile-j516m',j516m_source),('measurement-refusal',identity_source)]:
   p=Path(temp)/name;p.with_suffix('.rs').write_text(code)

Signed-off-by: Benjamin Nguyen <hungbenjamin402@gmail.com>

If you would rather admit any 30-core 8/8/7/7 J516M bin than add masks one at a time, the same data supports that. I followed the existing policy of admitting only measured masks.

[scottjones]

Thanks for this, it's a really thorough report. A second J516M with a different core mask is exactly the data we needed, and it's great to see the 120 Hz, DPMS and s2idle results hold up on another Mac.

#415 is Daniel's work, and we've carried it forward in #429 (#429), which supersedes it. #429 already does what you suggested at the end. Commit b4cff0e ("drm/asahi: g15: admit any 30-core J516M bin, not one Mac's core mask") checks the G15C version and counts plus exactly 30 enabled cores, and the existing per-cluster check still requires every cluster to be non-empty. Your mask 0x73df57f5fd has 30 cores split 8/8/7/7, so it should be admitted without a patch. Thanks for putting together a151931 with tests, but we won't need it. To be clear, we've only checked your mask against the code, not booted #429 on your Mac.

#429 also makes the display and GPU default-on, so the apple_t6034_display.enable=1 opt-in you found easy to miss goes away. It pairs with omacom/m1n1#42 (omacom/m1n1#42), which builds on m1n1#32 and makes the loader side default-on too.

HDMI and USB-C to HDMI are deliberately out of scope for this carry.

If you have time, could you boot #429 plus m1n1#42 with no opt-in lines (none in /etc/m1n1.conf, nothing on the kernel command line) and without your mask patch, and share:

• the asahi-g15 lines from journalctl -k -b | grep -i g15
• the "cores enabled per cluster" line
• whether /dev/dri/renderD128 is present
• the display mode you get

That would give us a second default-on J516M test, on a different bin. To go back afterwards, reinstall your #416 and m1n1#41 packages and restore your opt-in lines.