[DjDeveloperr]

Turns the GPU on by default wherever the driver is ready: the M3 Pro and M3 Max backend (G15) and the M4 backend (G16) are built by default, G16 autoloads instead of needing a manual modprobe, and the M4 Max GPU node is enabled.

What changes

• G16 autoloads. apple,agx-t8132 is now in the module alias table. Its probe already deferred for the PMP supplier and the GFX power domain. It now also waits for a native display the boot loader handed over, through a new T8132 publication slot in drm/apple (apple_drm_t8132_link_device(), the same mechanism G15 uses on T6030 and T6031). A boot with no handed-over display (a Mac mini, a panel without a qualified profile, a refused handoff) starts the GPU on the boot framebuffer.
• G16 pins its module with try_module_get() before power admission, as G15 does since 1cf5527. With autoload, a deferred probe can race rmmod.
• Kconfig. DRM_ASAHI_G15 and DRM_ASAHI_G16 default to y, "(experimental)" is gone, and asahi.config gains CONFIG_DRM_ASAHI_G15=y. G16 now depends on DRM_APPLE_DCP_T8132 and on drm/apple being built in or both being modules, like G15. The old G16 help said suspend, hibernation and kexec are blocked while native graphics owns DMA. No code does that, and the J713 GFX domain is apple,sleep-retained since 4b2b3de, so the help now says the firmware keeps running across suspend-to-idle.
• T6041 DT. gpu and gfx_mbox were disabled in t6041.dtsi, and aura#68 fills only an enabled T6041 GPU node, so the M4 Max GPU never probed. arm64: dts: apple: t6041-j616c: describe the GPU (stacked on #914) #917 was closed on the belief that the loader enables it; it doesn't. aura's fill still disables the GPU on any unexpected ADT data.

Per chip

Chip	Works today	What makes it work	What still blocks "out of the box"	Risks
T8132 (M4)	J713 G16 runs, after a manual load	this PR (autoload, default y)	J715: aura's display handoff is J713-only (its kernel panel profile exists). J604, J773g, J623, J624: the Air-only PMP, PMGR, thermal and display gates and aura's J713-only GPU handoff. #1171 and the aura PR move both to the 26.6.2 firmware	none of the non-Air boards has run this
T6040 (M4 Pro)	yes, J614s, J616s, J773s	already on (G17)	nothing	none new
T6041 (M4 Max)	yes on J616c with a hand-enabled node	this PR (DT) plus aura#68	the kernel admits only the 25F84 (26.5.2) image; a 26.6.2 stub loads 25G83, which needs #1050. The shipped Mesa (c1753704) refuses G16C; mesa#85 on aurora-wip fixes it, so the distros need a Mesa pin bump	J614c and J575c not run
T6030 (M3 Pro)	G15 runs if the kernel was built with G15	this PR (default y)	nothing in the kernel; aura enables J514s and J516s by default with the 14.8.3 G15S image	suspend-to-idle with the GPU running is unqualified: the T6030 GFX domain isn't apple,sleep-retained and G15 has no system-sleep callbacks, which is what broke J713 resume before 8fd377b
T6031 (M3 Max)	G15 on J516c if built with G15	this PR (default y)	J514c needs asahi,t6031-gpu=1 in aura's config	same suspend gap; omacom/linux carries a T6031 system-sleep hold (g15_sleep_hold) that isn't in this tree
T8122 (M3)	no, m3::refuse_probe()	the #964 stack, now merged with this base (separate pushes)	the stack is unreviewed and admits only the J613 on 26.6.2; J615 is opt-in and J504/J433/J434 aren't admitted; Mesa #163 (G15G) is open; the default-config CTS run hit a firmware fault	s2idle untested; asahi.t8122_start=0 doesn't stop the Extended path
T6034 (M3 Max, 30-core)	no	nothing exists	no driver match for apple,agx-t6034, no aura handoff, no Mesa id
T6032 (M3 Ultra)	no	nothing exists	no GPU node, aura refuses the chip, Mesa refuses two-die G15D

Testing

• build kernel --profile asahi -- Image modules dtbs with Rust on, alone and together with M4: take the PMP, PMGR, display and GPU paths on the 26.6.2 firmware on every M4 Mac #1171: no warnings. aurora.ko has CONFIG_DRM_ASAHI_G15=y and G16=y. Its alias table differs from the module running on the M2 Pro (7.3.0-1-21-ARCH) only by of:N*T*Capple,agx-t8132. Every M1 and M2 alias is unchanged.
• The only DT change is t6041.dtsi. The three T6041 dtbs differ from the base only by the two removed status lines. The M1 (J274), M2 (J413, J414s) and T6040 dtbs I built are byte-identical, and dt-validate shows nothing new.
• The full host suite (tools/asahi/run-host-tests.py) passes 195/195 with this PR and M4: take the PMP, PMGR, display and GPU paths on the 26.6.2 firmware on every M4 Mac #1171 together on 72b828e.
• g15-display-order-tests.py gains a T8132 scenario. All 12 C mutants are caught, including four new ones: the T8132 slot read or published as T6031's, ignoring a handed-over display, and waiting without one. The display host tests pass 5/5.
• I don't have an M3 or M4 machine, so nothing here has run on one. The M2 Pro was not rebooted.

Base

Rebased on integration/aurora 72b828e, after #1166: the T6041 GPU node and its mailbox (now agx_mbox) lose their status = "disabled" in the reorganized t6041.dtsi. The old t8132-j713-gpu.dtsi comment edit is gone with that file. #1171 (M4 firmware path) extends G16's board check to every M4 Mac on 26.6.2. Each PR builds on its own.

Related PRs:

• kboot_gpu_m4: publish the G16 handoff on the 26.6.2 firmware on every M4 Mac aura#106: the M4 GPU handoff follows the 26.6.2 firmware instead of the J713 board.
• linux-aurora: build the M3 Pro and M3 Max GPU backend alarm-aurora#168 and kernel: build the M3 Pro and M3 Max GPU backend nixos-aurora#172 turn G15 on in the resolved distro configs; ALARM goes first.
• Fedora needs no change: it merges this asahi.config into a base config that never sets G15.

Mesa gaps:

• The distros pin aurora-silicon/mesa c1753704, which refuses the M4 Max (G16C). mesa#85 on aurora-wip maps it to G17P, so the M4 Max needs a Mesa pin bump.
• The M3 (G15G) needs mesa#163, which is still open.
• No Mesa branch drives T6032 or T6034.

🤖 Generated with Claude Code