[samucarre]

On the T6031 (M3 Max) the G15 GPU is powered by its PMGR domain alone (Platform::DeviceTree): there is no RTKit AGX vote and nothing sets the AGX PTD power request. As 9bb7476 found on T6030, PMP then ignores the GPU's bandwidth demand and memory stays at its idle floor.

Change. apple_pmp_report_t6031_gfx() in pmp-report.c, called once from start_backend() after init_graphs() on the DeviceTree platform. In the J516C apple,tunable-soc-device table AGX is soc-device ID 14 (record 13, acknowledged; ID 5 on T6030), so the T6030 code cannot be reused as is. The function finds the unique T6031 report, checks record 13 is AGX with the ACK flag and that PMP reports ready, then clears and sets bit 13 (an earlier request is acknowledged without enabling bandwidth scaling, as on T6030). On failure it only warns, clears the request (the previous behaviour) and the GPU keeps running. The request stays until reboot, like the retained session. New hidden option APPLE_T6031_GPU_PMP_REPORT, selected by DRM_ASAHI_G15; other SoCs get -ENODEV and nothing changes.

Checked on a MacBook Pro 16" M3 Max (J516C, 64 GB), integration/aurora 30a6518 plus local patches (HDMI on dcpext0, J516C panel brightness, AVD AV1, in-flight cap):

• boot log: G15: PMP AGX request set (memory bandwidth scaling)
• test-backend-ops perf -o CPY -b Vulkan0 (Aurora Mesa, unchanged): 1.5 GB f32 copies 75 → 316 GB/s, 768 MB f16/bf16 copies 56 → 200 GB/s
• test-backend-ops test -o CPY: 254/254 OK; panel, HDMI, brightness and AVD keep working
• builds cleanly on 30a6518 (arm64, clang 21) together with my three other PRs of today, which touch other files

Not checked. Other T6031 boards; this branch alone on hardware (it ran on top of the local patches above); suspend/resume.

🤖 Generated with Claude Code

[chriskearney]

Reviewed all seven changes at exact head bb0d66e5ad7b72ff6f9d0e7656a376274871cc2b and the independent current-merge, request/ACK, rollback, lifetime and Kconfig/linkage analysis. The existing J516C G15 admission is preserved; the helper validates the unique T6031 report and AGX record before the bounded clear/set handshake. The persistent request changes functional bandwidth/power behavior. Independent exact-function mocked controls passed 26 cases; five semantic mutants compiled and failed intended assertions. No concrete source blocker found.

The author's J516C throughput and 254-copy observations are attributed to a mixed local stack, not an exact-head hardware qualification. Error cleanup is best effort; a warning is not proof of acknowledged idle state. #258 alone is not a sleep fix, and #288/firmware/panel holds remain separate. Exact-candidate performance, idle/power and release claims still need actual hardware evidence.

Normal current CI and full merge-group C/Rust/PMP module build, KUnit, boot and result checks remain required. The old held run is not a pass. No extra generic physical boot is required solely for merging this bounded source change; QEMU would not qualify PMP bandwidth.

[malik-na]

Tested on a MacBook Pro 16" M3 Max (J516C, 64 GB) through Mac Lab, as two kernels that differ by this one commit: 30a65186 (control) and bb0d66e5 (control plus this PR). Both booted with the same cmdline, three runs each in the same job.

	control 30a65186	with this PR bb0d66e5
glmark2 (off-screen)	729 / 720 / 726	1097 / 1141 / 1107
vkmark	3301 / 3316 / 3294	5603 / 5568 / 5515

• Average: glmark2 725 to 1115 (+54 %), vkmark 3304 to 5562 (+68 %).
• Boot log shows G15: PMP AGX request set (memory bandwidth scaling).
• Health: boot-health passed; omarchy-m-test had 0 regressions against the control.
• One difference in the boot errors: the boot with this PR has an extra irq 81 dump (apple_spmi_irq_handler, bad_chained_irq, SPMI controller). The control boot does not show it. That is one boot each, so I cannot say it comes from this PR.
• Not checked: one machine only; suspend/resume; other T6031 boards; the copy-bandwidth numbers from the PR description (those need test-backend-ops, which is not packaged on the lab Mac).