[erykwieliczko]

<ai>

On my J514S M3 Pro, integration/aurora at b6f070c91193 boots without a GPU render node. The display gate logs:

apple-t6030-display: PMP not added: /soc/pmp@350500000 already exists

This fixes two startup issues:

• Guard the four static T6030 PMP nodes with APPLE_USE_PMP, matching the existing alias and consumer guards. They otherwise conflict with the display gate's runtime overlay.
• Match UAT reservation names such as uat-ttbs@10 with of_node_name_eq(). The exact-path lookup misses them. Keep the unique-owner and range checks, and add regression coverage.

The UAT test passes with the fix and fails against the old lookup. CI also checks the PMP nodes and alias in J514S/J516S DTBs built with and without APPLE_USE_PMP. The surrounding G15 and PMP host suites also pass.

The same production fixes passed native GL/Vulkan readbacks and three PB reclaim cycles on be6381f9d2a5, using native G15 Mesa 132fff8452a4.

</ai>

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable defects were found.

Summary

This PR fixes two barriers to M3 Pro GPU startup:

• M3 Pro trees leave runtime PMP nodes to the display gate by default.
• G15 finds reserved UAT regions when their names include unit addresses.

It also expands UAT regression coverage and adds checks for both PMP profiles on J514S and J516S. No actionable issues were found. Tests were inspected, not executed.

_{Reviews (2) · Last reviewed commit: "drm/asahi: g15: match UAT reservations w..." · Reviewed by Greptile}

[chriskearney]

Thanks, Eryk. Reviewed 91c22e90236e against b6f070c91193; I didn’t find a source blocker.

The reservation lookup handles unit addresses without weakening the owner checks: duplicate names still refuse, including a disabled duplicate, and the exact range, availability and reusable checks remain. The child and parent references balance. Guarding all four PMP nodes also matches the existing alias and consumer guards.

Independent checks:

• G15 host suite: 74 Rust tests passed, 2 ignored; the C memory, UAT-owner and PMP-bridge checks passed.
• Your new UAT fixture fails against the base lookup. Seven deliberate faults in duplicate/name matching, reference handling and range checks all built and failed at runtime; controls passed before and after, with ASan/UBSan enabled.
• J514S/J516S DTs built with and without APPLE_USE_PMP, using this tree’s dtc. Default builds omit all four PMP nodes; static builds retain them and are byte-identical to the base. J313, J613 and J516C comparison DTBs also remain byte-identical.

One non-blocking test suggestion: keep those default/static PMP node-presence assertions in CI. A successful DT compile alone would not catch the original runtime overlay collision.

Both commits still need your Signed-off-by trailer to clear ci / commits; compile, device-tree and both host-test jobs have now passed. I haven’t boot-tested this PR or run a full local kernel build. Review assisted by Codex.

[erykwieliczko]

Done.

[maralcbr]

Thanks @erykwieliczko, both fixes are right and small. Looks right to me, no blockers.

• Static PMP nodes. On b6f070c91193 the four nodes at t6030.dtsi:839-986 are always present. The gate refuses on any node with the PMP or report compatible, disabled or not (t6030-display-gate.c:692-698). So every J516S, and every J514S whose boot loader passes PMP values, hit "already exists" and stayed on the boot framebuffer. Every reference to the guarded labels was already under APPLE_USE_PMP (alias :22-24, AVD :731, ANS mailbox, SART and NVMe :1399, :1409, :1428). Neither board defines it, and the overlays carry their own four nodes, so nothing dangles and nothing collides. T8122 and T6031 reuse their static PMP and are untouched.
• UAT owner lookup. of_find_node_by_path() compares the full node name, so it could never match uat-ttbs@10 (t6030-gpu.dtsi:47-66). of_node_name_eq() with the unique-owner count is the right fix. The references balance, a missing /reserved-memory is safe, and the range, availability, reusable and single-reg checks are unchanged. m1n1 fills the existing placeholders in place, so refusing duplicates won't reject real hardware.

What I ran: the G15 host suite passes locally (74 passed, 2 ignored, plus the C checks). The UAT fixture passes under ASan/UBSan and aborts at uat-owner.c:119 against the old lookup. t6030-pmp-dt-tests.py with the tree's own dtc passes all four profiles, and on the base tree it fails on the J514S default profile. check-commits.py shows both commits signed off. CI is green at 8b0cbd5, and the host tests (tools) log shows the new suite's setup and all four profiles passing. Since @chriskearney's review at 91c22e90236e the production code is unchanged: the sign-offs and his suggested DT assertions are in.

Optional, fine as a follow-up:

• Assert on what the gate checks. t6030-pmp-dt-tests.py:12-17 matches direct /soc children by name. The gate searches the whole tree by compatible (apple,t6000-pmp-v2 and apple,t6030-pmp-v2-report, t6030-display-gate.c:693-695). A static node added later under another name, for example the overlay's own pmp-report@/mailbox@ spellings, would pass the test and break the gate again. Could the default profile also assert that no node carries those two compatibles?

For release (not the merge): boot-critical for every M3 Pro, since default kernels now take the native display handoff and start the PMP. Before release I'd want cold boots of the final artifact on a J514S with loader PMP values and on a J516S, each with the native display up, a render node, and a GL/Vulkan readback. I'd also want one boot with apple_t6030_display.enable=0 to confirm the framebuffer fallback without the static nodes. Your readbacks were on be6381f9d2a5, so a run at the final head would close that. The merge queue's full run (KUnit, package, boot) still applies as usual.

[maralcbr]

Optional: the gate refuses on the apple,t6000-pmp-v2 and apple,t6030-pmp-v2-report compatibles anywhere in the tree (t6030-display-gate.c:693-695), not on these names. Asserting that neither compatible is present in the default profile would catch a renamed static node too.

[chriskearney]

Boot-tested 8b0cbd58bf95 on J516S/T6030 with the matching J516S DTB and unchanged loader executable.

Full Image/modules/DTBs build passed. The kernel booted in 30 seconds and native G15 started with the unit-addressed UAT reservations, exercising the new lookup. OpenGL and Vulkan pixel readbacks passed with zero wrong pixels. No kernel WARN/Oops/SError, DART faults, GPU faults, recoveries or hang kills were observed during the scoped checks.

The updated default/static PMP regression test passes too. No kernel/GPU blocker found in these two fixes. This was one boot and scoped graphics validation, rather than full hardware qualification. Review/testing assisted by Codex.

[chriskearney]

Reviewed 8b0cbd5. Full kernel build, host regression checks and a J516S boot with the matching DTB passed the scoped startup/graphics checks. The unit-addressed UAT reservations were exercised on hardware; GL/Vulkan readbacks passed with no GPU/DART faults observed. No blockers found in these two fixes. Review assisted by Codex.

[joshuaswarren]

Tested on the lab laptops as part of a combined hand build (also carrying 186, 183, 179). Posted here for 202.

What was built

• Head tested: a565165 (t6030.dtsi, g15/glue.c, selftests uat-owner.c, all three blob-verified against the compare API).
• Combined hand build, release 7.2.11-newprs-ARCH+ (sha256 3c0cab28f7532a88a2a5828ea9f3d69612a48fbc1ee8cd464a4f1b8a22c017f5), base the 7.2.11 base d8ecb2e (plus the drm/apple sibling files noted in the 183 thread; this PR's files do not overlap with any other PR's).
• Compile receipt specific to this PR (the lab kernel configs build the asahi module without G15, so the meaningful check is a scratch build): separate out directory, olddefconfig with CONFIG_DRM_ASAHI_G15=y, make W=1 drivers/gpu/drm/asahi/g15/glue.o -> builds with zero W=1 warnings in glue.c; make apple/t6030-j514s.dtb apple/t6030-j516s.dtb -> both device trees build clean. The G15 code was compiled but never ran (no M3 Pro/Max hardware in this fleet). CI at time of posting: ci/compile and ci/device trees pass on the branch.
• The selftest file (uat-owner.c) is in the tree; the selftest harness itself was not run.

Boot regression check (the lab fleet has no T6030/T6031, so the boots prove the g15 change does not break the M1-family/M2-family build):
| Machine | SoC | boot id (candidate) | boots | GPU smoke vs baseline |
| 13-inch M1 MacBook Pro | T8103 | e8c0ca63-b566-444f-b2af-25ecce9982f6 | yes | gpu-compute PASS, same max_abs_err; gpu-dmesg clean; asahi module loads |
| 14-inch M2 Max MacBook Pro | T6021 | 64a04d28-8325-4ffc-8bfc-06b1e2d447d7 | yes | gpu-compute PASS, same max_abs_err; gpu-vulkan device enumerates; gpu-dmesg clean |

Both candidates boot one-shot with 0 failed units, smoke suites equal to the machines' own stock baselines, no new dmesg error class. The g15 driver code is not used on T8103/T6021, so these boots say nothing about M3 Pro GPU startup behaviour - that path is exactly what was NOT tested (no hardware).

Regressions: none found. The 16-inch M1 Max run is pending (its lab window was taken by other tests); I will add one line to this comment thread when it ran.

[joshuaswarren]

Hand build of the integration/aurora tip 7b96998 (contains the merges of this PR and #199, #202, #203, #204). Package release 7.2.11-tip-ARCH+, package sha256 52830bb4538e8e8f5344eacff87fbdb9ab26cc553540c36e993ba4e097561c23.

Tested so far (one-shot boot only, stock untouched):

machine	boots	result
14-inch M2 Max	yes (candidate boot 3c4b9246, return 1beecd62)	smoke equal to stock; omarchy-m-test 0.1.13: https://omarchy-m-testing.org/reports/6qHb7QcJkwg2Ref7zubzgZuA (stock reference: https://omarchy-m-testing.org/reports/RVXdswZ8LJoUJKF7vRh2KAHf)
13-inch M1	pending — machine reserved for an all-night test run; will add a line when it ran
16-inch M1 Max	pending — same

CI on this PR: 9 pass, 4 skipped (attest, KUnit, boot, package).

Regressions: none found. dmesg error classes on the candidate boot match the stock baseline (known flakes only: dp-xbar -517 deferrals, brcmfmac join_pref/assoc noise, Bluetooth codec-capabilities -110). m-test check list identical to stock except two tool-level deltas, neither a functional failure: (1) hardware.drivers counts apple,mesa-fingerprint unclaimed on the tip (the node exists, no functional impact seen); (2) sep.attach reads SKIP because the SEP diagnostics ABI moved 1 -> 2 and the tool's reader expects 1 — the driver itself is up on the tip (apple_sep loaded, SEP platform profile T6020/J414s, xART scanned, trusted-keys registered, endpoints discovered), and the audio.microphone checks still pass.

Not tested: M3 paths (this PR's T8122-without-G15 build path is M3-family; the M3 Pro GPU startup in #202 and the J615 camera path in #203 compiled and booted in this build on M1/M2 but their M3-only code paths were not exercised — no M3 machine in this lab).