[chriskearney]

The normal kernel build omits the T8122 and G15 GPU runtimes, so system Mesa alone cannot accelerate supported M3 models. Enable those runtimes and let an omitted T8122 startup parameter select the existing J613/J615 board policy. Explicit startup-off, invalid-parameter refusal, firmware/resource checks and the conservative state-2 cap remain intact.

Merge prerequisite: omacom/linux-aurora#236 must land first. It adds the one-start-per-boot latch and conservative packet-publication tracking requested in the runtime review. This PR remains held pending that dependency and review of the resulting composition.

G15 retains its existing J514S/J516S Pro admission and T6030-only autoload. Max still needs explicit loading and its existing display/model gates; Ultra admission is unchanged. Scott’s follow-up withdrew the request to split G15 enablement. Standard mesa-aurora/vulkan-aurora packages are the RC path; experimental mesa-m3 login hooks are outside it.

At signed-off head fc5391123e5ab821f6143456bab21a0dfe78784a (source tree unchanged by the sign-off correction), the old opt-in-only SoC note and disabled-start diagnostic now describe board defaults and explicit asahi.t8122_start=0. The adjacent SoC documentation is corrected too. This follow-up changes text only.

Validation of the prior 8a31fe1856860fad834882729201855e758b45c8 source:

• 21 host policy/identity tests and 54 focused Kconfig checks passed. The subsequent full source CI run 40255325852 passed package, KUnit, boot and result checks.
• Full native production preview and final 7.2.11.aurora7-1 packages built. Actual Image/header configurations match, Rust/G15/T8122/16KiB are enabled, and the AArch64 Asahi module has matching vermagic with all 456 undefined symbols resolved in shipped Module.symvers.
• These artifacts do not include drm/asahi: m3: one GPU firmware start per boot, and quarantine only published packets #236 or the new text follow-up. They are prior-source evidence; the final dependency composition needs fresh source/CI/package validation.
• Compared with packaged aurora6, five resolved options change: G15/T8122 plus their existing UAT-adoption and GPU-PMP dependencies. Nonfatal Rust/rustfmt/headers-helper strip diagnostics remain disclosed; external-module/DKMS execution was not tested.

No new model boot, GPU, login, fresh-install or upgrade qualification is claimed here. Packaging is tracked in omacom/omarchy-pkgs#1622.

[chriskearney]

Final source/build check at 8a31fe1: no confirmed blocker in this four-file change. The only behavior change in T8122 startup is UNSET + existing admitted Air board → On. Explicit off and malformed values retain their prior behavior; downstream firmware/resource admission and the state-2 performance cap are retained. Existing G15 model/autoload boundaries are unchanged. The source includes #214/#183 and excludes #226–229.

The full native production-recipe preview built successfully as 7.2.11.aurora7-230.1. Both packages and built PKGBUILD were independently rehashed. Image and headers configs match (f1bdda16b2b0069eb9c3e7fdcce85d3034b77db3badc0e2ef754d0a3640dc801); Rust/G15/T8122 and 16KiB pages are enabled. The real AArch64 Asahi module has matching vermagic and all 456 undefined symbols resolve against shipped Module.symvers. The production input/config/helpers are unchanged; only source pin and preview pkgrel differ. Nonfatal Rust/rustfmt and headers-helper strip diagnostics remain disclosed; external-module/DKMS execution was not tested.

This is source/native-build evidence, not a new model boot or graphics qualification. The final aurora7-1 recipe is pinned in omacom/omarchy-pkgs#1622. Standard system Mesa is the intended RC path; experimental mesa-m3 login hooks are outside it.

Package SHA256: kernel ff4ca6828a904acb8805c7331ee53dd81a3e6e0f6ccd110d6c6f129c1f1be0f6; headers 56bdfae8b58ab647d6f5b44b34a77919aed8a246cbbd670f870fbd4fa78d2775.

[scottjones]

We read 8a31fe1 against Marcelo's list from #187. The start default looks right to us. With every knob unset, it gives exactly the values J613 has been running with: initdata 0x0c08e21e83800490, fender 0x104000, clkgen e1c, sgx_setup t6030, unit masks 0x700000003 and 0x7, pstate cap 2. That matches the armed line on our Air this boot, and t8122_start=0 still turns it off.

Three things before merge:

1. The two runtime fixes need to land first. Marcelo asked for the one-start-per-boot latch and the "may have been published" packet flag in or before the switch-on. Without the latch, an unbind and rebind boots the firmware a second time on freed tables. We have both in #236, which touches only m3_runtime.rs, m3_submit.rs, the batch policy and its host test, so it doesn't conflict with this.
2. G15=y is a separate decision. Since #204, the Air option no longer needs G15. With CONFIG_DRM_ASAHI_G15=y, the M3 Pro/Max (J514S/J516S) move to the G15 backend, which Marcelo listed as its own decision. Could that be its own PR, so this one only switches on the Air? We resolved omarchy-pkgs' package config with this asahi.config, both as is and without the G15 line, and validate-config.py accepts both. The only difference is G15 and the T6030 PMP link.
3. Stale text. Two strings still say the GPU starts only with asahi.t8122_start=1: the T8122 unported note in m3_soc.rs, and "values given without asahi.t8122_start=1; ignored" in arm(), which now fires only with =0.

[scottjones]

On point 2: we've since heard both paths have been tested, so keeping G15=y in this PR is fine with us. The other two points stand: #236 first, and the two stale t8122_start=1 strings.

[scottjones]

Approving at fc53911: the start default matches what our J613 runs with, both paths have been tested, and the stale t8122_start=1 strings are fixed. Please merge #236 (the one-start latch and the published-packet flag Marcelo asked for) first.