Skip to content

drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora - #1012

Merged
DjDeveloperr merged 166 commits into
integration/aurorafrom
funkzy/t6050-gpu-on-integration
Nov 10, 2026
Merged

drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora#1012
DjDeveloperr merged 166 commits into
integration/aurorafrom
funkzy/t6050-gpu-on-integration

Conversation

@funkzy

@funkzy funkzy commented Nov 6, 2026 •
edited by DjDeveloperr
Loading

Copy link
Copy Markdown
Contributor

Current consolidated M5 bring-up status

Frozen ending head: 65bb111d95457ec5beffa5b1b203d0979671c9df
Complete tree: 4dc6dfa83f0d1872f653527d0f83e73fc6ff27bb
Integration cutoff: c1c3dc53d8d9344488fd25855fa2180494a4d1ba

The original detailed write-up below is retained as historical context; statements there about earlier refusals, exclusions or commit counts do not override this consolidated status.

Original earlier Ultra/Max development write-up and historical validation

What this is

M5 GPU and display support on integration's drivers, tested on a bare-metal M5 Ultra (Mac Studio, J775D). The M5 Max (J716c) now runs too.

  • No SPTM needed. The GPU runs with driver-owned page tables.
  • The display moves from firmware 26.6 to 27.0. The M5 Ultra boots 27.0 at the lowest, so without this there is no display output.
  • Based on integration/aurora at 33bec40, linear with no merges, 136 commits (12 of them update integration's host-test harnesses to follow the series). The tip builds with integration's config (defconfig + asahi.config, all modules through modpost) and with every backend on; per-commit builds follow (see Testing).
  • Fits beside integration's other new GPU backends: the separate T8142 M5 backend (DRM_ASAHI_M5), G18 and G15 all build and keep their own bindings and payloads.

How the series is organized

  1. The M5 driver (dj), rebased onto integration's G17 driver with the SPTM parts removed. Each commit notes the range it came from.
  2. M5 Max support (ewb), backported. It covers the J716c hardware data, AON records and probe, render blocks, the minimum parameter-buffer size, the compute queue reinstall, and MMU fault blame.
  3. Firmware-27 display (dj), backported.
  4. J775D / M5 Ultra support, performance work and fixes (funkzy), on top.
  5. The M5 Max running on bare metal (ewb, from aurora-silicon/linux#1056): the MCC mask and topology words for J716c, J716c controller defaults, running the M5 Max on bare metal, and matching the T6050 GPU by apple,agx-g17s.
  6. Three fixes from the review and its testing (funkzy), last: rmmod racing a GPU or display probe, and queue creation spinning a CPU (see Changes after review).
  7. Two render pairs per M5 Ultra render queue (funkzy, on dj's and Ryan's work), last (see below).

Commits from other authors carry only conflict resolutions and review fixes, each noted in the commit.

What's in it

GPU (drivers/gpu/drm/asahi, g17):

  • M5 boards: J775D (M5 Ultra) and J716c (M5 Max), matched on the board's clusters and core slots. Both run; only the M5 Pro is still refused at probe.
  • The GPU binds by apple,agx-g17s. An M5 Max node lists apple,agx-g17c and an M5 Ultra node apple,agx-g17d, each with apple,agx-g17s as the fallback (the nodes come with arm64: dts: apple: add the J716c (MacBook Pro 16-inch, M5 Max) #945; see Dependencies).
  • Bare-metal M5 support: the firmware identity and its boot-filled ranges, the board table, the UAT pieces for driver-owned page tables, and the M5 Ultra's clock and performance floors.
  • M5 render and compute submission, the M5 free-list layout, sparse tiles and context pins.
  • An opt-in M5 thermal governor (off by default), with fan requests through macsmc.
  • Two small changes outside drm: rust: drm: gem: shmem: Offer core-created objects only to full allocators and hwmon: macsmc: Accept fan requests from a kernel thermal policy.

Performance: on M5, GPU completion and scheduler work run in the submitting client's cluster, so jobs complete up to 20% faster from either die of the M5 Ultra. This is M5-gated, with two small Rust bindings (workqueue, drm_sched) to support it.

Display (drivers/gpu/drm/apple):

  • dj's firmware-27 support for T6050, with the analytics replies.
  • T6050's locked display roots and four-level firmware subtrees in apple-dart.
  • Firmware-27 surface sizes, a dcpext EDID built from the sink metadata, and port rules keyed on the profile.
  • "Fix no display on a T6050 with more than one DCP": the loader has one boot framebuffer, so the other DCPs now bind without one.
  • "Fix one failed DCP taking down every display output."
Fixes from a review of the series
  • Fix one client's binds being able to crash the GPU for every client
  • Fix hung GPU work running on with no time limit
  • Fix a process keeping access to a GPU queue after another process takes it
  • Fix a released context's QoS entry pointing at memory another process reuses
  • Fix client binds silently replacing the kernel's GPU mappings
  • Fix compute jobs overrunning their scratch pool
  • Fix one client exhausting system memory through GPU pool sizes
  • Fix one client taking every GPU queue from the others
  • Fix sparse tiles wasting 2 MiB of contiguous memory per GPU VM
  • Fix a bad firmware table pointer making the driver overwrite kernel memory
  • M5: Fix GPU jobs being able to write the kernel's completion and scheduler pages
  • Fix clients rewriting submitted GPU commands after the kernel validated them
  • Fix display firmware buffer requests reaching any mapped memory
  • Fix GPU job fences being able to stall memory reclaim under memory pressure

Several touch shared G17 or display code. Each commit says which paths and GPUs it covers.

Changes after review

dj's review of the first posting is folded in. Each fix sits in the commit it belongs to, with a note on others' commits. Two new commits close the module-unload race, and a third fixes a CPU spin that testing found.

Must fix:

  1. Feature bit: staged renders are reported under bit 33, since integration gave 31 and 32 to G18. Mesa drm/apple: audio: open the DCP PCM without a sink, and release data_lock on a DMA error #169 follows.
  2. A faulted client's GPU state is freed again. Teardown had started waiting for a published kill before counting a render pair as idle, but the kill was only published after teardown, so a context whose renders ran unstamped kept its context, scheduler page and render pairs until the GPU stopped. The stricter rule now applies only to releasing the scheduler.
  3. GPU recovery no longer blames or cancels innocent work on G17P. G17P's recovery table is a packed list whose records after the first invalid one are leftovers, so its walk ends there again. Walking every record and skipping invalid ones is M5-only.
  4. rmmod can't unload code an M5 session still runs. An M5 session kept at unbind now pins the module with try_module_get(), so rmmod is refused instead of leaving firmware callbacks pointing into freed code.
  5. M5 work the GPU can't run is refused at SUBMIT. Compute with a sampler heap and the depth/MSAA renders M5 doesn't support fail validation with EOPNOTSUPP, instead of being accepted and then failing, which Mesa treated as a lost device.

Should fix:

  • Queue cap per process, not per open file: queues count against the creating process across all its files, so reopening the device doesn't reset it. A process may always hold half the queues; beyond that it must leave an eighth free while another process holds one. A process alone can use every queue the GPU can still create.
  • M5 pool memory is counted once, as the client's own memory, so a 16 GiB pool takes 16 GiB of the device limit, not 32. When another client reuses a pool's storage, the charge moves to it.
  • Kick rings: on M5 the render kick rings and command descriptors in the kernel's upper half are firmware-only, as compute's already were. Each render now maps only its own metrics entry, instead of every VM mapping the whole metrics backing read-write.
  • UAPI: bits 24 and 25 are retired for good (see UAPI).
  • Display:
    • The firmware buffer guard also refuses addresses below DRAM, where every device's registers sit, so unclaimed register windows are covered.
    • A T6050 external display's probe now waits, bounded by the deferred-probe timeout, for what bind needs, so a deferral no longer becomes permanent.
    • The EPIC unit rule and the Activate reply on a PHY error apply to firmware 27 only; the T8140 and other firmware parse and reply as before.
  • Smaller:
    • GET_PARAMS no longer reports BOUNDED_AS_BUILD on M5, whose command set refuses it.
    • Unused render-ring storage is reused by the VM that created it, or by any VM once that one is closed.
    • A released QoS entry that was busy is cleared once its work completes.
    • The header documents scs_layout and cdm_auxiliary_allocation as they are used on M5.

Also:

  • Race-free module pins in every backend and the display driver. G16, G18, integration's T8142 M5 backend and the display driver's DCP sessions pinned the module with __module_get(), which an rmmod already under way doesn't stop. They now use try_module_get(), so a probe racing rmmod is refused with nothing started.
  • Ray-query jobs on M5: the long-job allowance for compute and render jobs also counts M5's intersection tables.
  • Queue creation no longer spins a CPU when the GPU has no room for another queue (found in testing). It sleeps until a queue slot or execution context is returned, and still fails with EBUSY after its timeout. Before, the creator woke itself at once and retried with the device mutex taken on every turn, over half a million times in 29 seconds.

Reasoned and build-checked only, with no hardware here: the G17P paths (2 and 3, and the queue-creation wait in shared G17 code), the T8140 display gating, and the G16, T8142 M5 and G18 module pins.

Two render pairs per M5 Ultra render queue (added)

Four commits on top, on 5b0f106. They combine dj's two-render-pair design from t6050-gpu (87cab74, 22516bf45e61), with its firmware ordering of overlapping renders (b141ca9), and Ryan's shared QID capacity on integration/aurora (780956a). Ryan's capacity rule protects one render pair per execution context and shares the rest, and set one pair per queue to fit it. These commits bring back dj's second pair on G17D from that shared surplus.

1. Fix: restore dj's two render pairs per queue on G17D, within Ryan's shared capacity (three commits)

  • From dj: two pairs per queue, credits sized as pairs × depth, and firmware ordering of overlapping renders, now also across a queue's own two pairs instead of a host wait.
  • From Ryan: one protected render pair per execution context. The second pair comes only from the shared surplus.
  • Quarantine after a fault covers both of a queue's pairs.
gpubench 1080p, µs per submit 1 pair 2 pairs 1 pair again
fill d8 41.97 38.13 (−9%) 41.98
geom d8 39.0 33.2 (−15%) 38.7

GPU time per render is unchanged; the gain comes from the two pairs overlapping.

2. Perf: take a queue's second render pair only once its first has a backlog, so depth-2 rows run 20–28% faster than always splitting (one commit)

With group 1 alone, a depth-2 queue switches pairs on almost every render and loses time. Stacking on the busy pair until it holds a backlog fixes that: fill d2 92 against 126, geom d2 102 against 127 µs. Depth 8 keeps the two-pair gain (fill 38.14).

Tested on the bare-metal M5 Ultra, with the same platform test layer as above:

  • KUnit: 243 pass, 0 fail.
  • Render CTS subset: 571 pass, 0 fail.
  • vkcompute, vkchain, vktimestamp and the 46-client burst pass.
  • 0 host waits, recoveries, faults or timeouts.
  • The tip builds with integration's config and with every backend on, with no warning beyond 5b0f106's own. Each of the four commits also builds on its own, with integration's config and with every backend and KUnit on, adding no warning over its parent.

UAPI

include/uapi/drm/asahi_drm.h defines the M5 render and compute interface: stage prefixes, whole-attachment renders, and the M5 compute and render resources.

  • struct drm_asahi_cmd_render stays at integration's 448 bytes. M5's stage prefixes are their own struct, struct drm_asahi_render_stage_prefixes, sent after the complete render command as struct drm_asahi_cmd_render_m5 (480 bytes). This is the same pattern as G18's render payload, so G18's payloads and size checks are untouched. The prefixes must be zero when the flag isn't set.
  • The 480-byte stage-prefix form is reported under its own feature bit, DRM_ASAHI_FEATURE_RENDER_STAGE_PREFIXES_V2 (bit 33). It is a #define after the enum, like G18's bit 32, because integration gave bits 31 and 32 to G18. Bits 24 and 25 stay defined but are retired: older Mesa uses them for 352- and 368-byte layouts whose prefix fields sit where this command carries its ray-query state, so no kernel may report them again. The header says so, and a build-time check keeps them out of the M5 feature set. So any Mesa and kernel pairing works; a mismatched pairing just doesn't send staged renders.
  • GET_PARAMS reports the M5 features only on M5.
  • DRM_ASAHI_COMPUTE_NO_QUERY_ACCESS (feature 30) is defined but not reported yet. Enabling it broke timestamp ordering in testing, so it waits for a follow-up.

Mesa:

  • From 6edf62bcfd0 on, public aurora-silicon/mesa agx3c accepts this kernel's "aurora" driver name, and its command layouts match this kernel's, except for the staged render.
  • On the boards here, agx3c runs the M5 Max (J716c) only with ASAHI_M5_BRINGUP=1, which is experimental. It doesn't support the two-die M5 Ultra yet. That support is a separate follow-up, and our J775D testing uses our own M5 Ultra Mesa.
  • Staged renders on M5 also need aurora-silicon/mesa#169, which takes this header as it is and sends the 480-byte form under bit 33. Without it, Mesa doesn't send staged renders and uses fragment barriers instead, which costs only performance.

Dependencies

  • Device tree: this series binds the GPU by apple,agx-g17s, but the T6050 GPU nodes and that binding are not in this PR. They come with ewb's DT series (aurora-silicon/linux#945). Until those land, no in-tree DT has a T6050 GPU node, so the GPU doesn't probe from the tree alone.
  • Platform pieces stay in their own branch: T6050 system-level cache allocation, the memory and fabric floor (the GPU probe waits for the CLPC), and the T6050 GPU mailbox.
    • Without the CLPC entry the GPU probe defers. A DT without apple,clpc probes with no floor.
  • CPU topology: the J775D cpu-map, its six L2 caches and the CPU capacities are a separate DT series, with CONFIG_SCHED_MC. The completion placement targets the submitter's cluster as the topology describes it.

Testing (bare-metal M5 Ultra, J775D)

On the posted tip (5b0f106). The runs used 62cd1cc, which has the same kernel code at the tip; the two differ in the host-test harnesses, and in KUnit test updates now folded into the commits that needed them. With the platform pieces as a test-only layer and a test-only DT node for the GPU:

  • Configuration: integration's documented build: make defconfig asahi.config, then olddefconfig, building Image modules dtbs. The GPU, display and NVMe drivers are modules. The only addition is a small J775D fragment: the T6050 DP PHY, and keeping the boot flash's write protection.
    • Booted with arm64.nomte. Our loader boots the kernel bare-metal and doesn't hide MTE, and no tag storage is set up there. That's unrelated to this series.
  • Boot: one-shot from our loader, read-only root, 0 writes on every NVMe partition. 0 WARNING, BUG or Oops; 0 GPU timeouts, firmware restarts or DCP crashes through the end of the window.
  • Feature bits: the kernel reports bit 33 (RENDER_STAGE_PREFIXES_V2), and not 24, 25, 31 or 32, nor BOUNDED_AS_BUILD (16).
  • GPU gate rows, with our M5 Ultra Mesa (see Mesa above): vkcompute 20/20, vktriangle 20/20, vktimestamp 10/10 in order, vkchain 300/300 (submit to wait return median 118 us). 0 bind refusals.
  • 46 concurrent clients: 46/46 pass in 2.1 s, with 0 EBUSY, ENOMEM or ENOSPC and nothing lost or timed out.
  • Staged renders:
    • A Mesa that predates bit 33: agx3c's layout, and a build that checks bit 31: vkcr 20/20 rounds exact each, 19 qualifying renders, none sent staged, none rejected. (On the tip before the queue-creation fix; that fix touches only queue admission.)
    • With aurora-silicon/mesa#169's two commits on our M5 Ultra Mesa: vkcr 20/20 rounds exact; all 19 qualifying renders go out as 480-byte staged renders (render flag 23), with 0 rejected, 0 EINVAL and no device loss.
  • Queue cap and refusal:
    • Alone, one process with two files gets 51 queues, every one the GPU can still create (24 compute channels in use), then EBUSY after the timeout without spinning a CPU: the refused create takes 2008 ms wall and 0.5 ms process CPU, and each retry the same.
    • With another process holding a queue, it gets 50, and a create past its share is refused at once.
  • Unbind and rmmod: after the unbind, the module stays pinned (refcount 1) and rmmod says it is in use. 0 kernel warnings.
  • Display: DP 3840x2160 and HDMI 1920x1080 on both DCPs, 0 refused buffers and 0 SErrors.
  • Build checks:
    • The tip builds with integration's config (defconfig + asahi.config, which also compiles the G16 backend), all modules through modpost: rc 0.
    • The tip builds with every backend on (G15, G16, G18 and the T8142 M5 backend, plus KUnit): rc 0, 0 warnings.
    • Per-commit builds on integration's config: every commit builds (120 of 120 before the host-test harness commits, which only touch tools/).
    • With every backend and KUnit on, the KUnit tests now build at each commit: their updates are folded into the commits whose changes they follow, instead of one catch-up commit near the end. The every-backend + KUnit builds at the changed commits are running, and their results will be added here.
    • The wording check on all 132 commits and their messages: clean.
    • Integration's host tests (tools/asahi/run-host-tests.py): the harnesses that extract code this series changes now follow it, without dropping or loosening any check. Every control and mutation passes or is killed as designed on the tip and on its merge with integration's head, run locally; the CI run on this push is the full-suite check.

On the series before the rebase:

  • Faults and timeouts: a forced GPU job timeout fails only that job, and the GPU keeps serving other clients. A compute-spin kill takes about 2 s.
  • Desktop: the desktop comes up on the GPU with no manual step. glmark2-wayland through zink scores about 3900.
  • Display: a DP replug under the desktop recovers.

Not in this PR

  • Device tree: the T6050 GPU nodes and the apple,agx-g17s binding (ewb's arm64: dts: apple: add the J716c (MacBook Pro 16-inch, M5 Max) #945, above).
  • Display: a hot plug on a USB-C port that was empty at boot (the link and mode come up, but there's no picture), firmware 27.2 (DCP probe refuses it; no panic), and HDMI/DP audio.
  • GPU:
    • the M5 Pro (refused at probe);
    • M5 compute off the device mutex;
    • lazy queue admission (open queues cap at about 126 today);
    • further isolation work;
    • enabling feature 30.
  • Diagnostics: dj's opt-in diagnostics are left out, and come as their own follow-up.

@funkzy funkzy mentioned this pull request Nov 6, 2026
Merged
@funkzy
funkzy force-pushed the funkzy/t6050-gpu-on-integration branch from 35fc02a to d078ca1 Compare November 6, 2026 07:08
@TripleU613

TripleU613 commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Hi, thanks for the M5 series. We run Linux natively on an M5 Pro MacBook Pro (J714s, T6050) and are trying to follow the right public work for its GPU.

From what's public: this PR runs the M5 Ultra on bare metal, and it deliberately refuses the M5 Pro at probe until bare-metal GPU tables exist. The related T6050 loader changes in aura were closed as carried in a non-public consolidated branch, and their GPU handoff targets the two-die Ultra.

Is there a supported public native path for the M5 Pro GPU, planned or in progress? If so, which branch or PR should we follow? We'd be glad to test public changes on a J714s when there is something to try.

@TripleU613 TripleU613 mentioned this pull request Nov 6, 2026
Open
@erikwb erikwb mentioned this pull request Nov 6, 2026
Closed
@DjDeveloperr

DjDeveloperr commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Must fix

  1. Feature bit 31 collides with the base.
  2. Neo regression: faulted clients never get their kill published.
    • Where: g17/runtime/render/teardown.rs:43, commit 4acee56c4a5.
    • teardown_idle() now waits for a published kill, but service_compute_exit() only publishes after teardown_idle() returns true.
    • So a context whose renders ran unstamped leaks its context, scheduler page and render pairs until the GPU stops. That happens on the Neo, and on M5 too.
    • The commit came from "a scenario sweep, not seen on the Studio". Keep the stricter rule only for scheduler release.
  3. Neo regression: recovery reads stale records.
    • Where: g17/recovery.rs:346, commit 4c62107745e.
    • The walk now reads all 256 records on every G17, but G17P leaves leftovers after the first invalid one. They blame and poison innocent VMs, or cancel bystander jobs.
    • Gate it on M5. The KUnit test with the matching name never exercises the walk, which is why nothing caught it.
  4. M5 sessions are leaked without pinning the module.
    • Where: g17/mod.rs:1806 (ManuallyDrop) and runtime.rs:2561 (forget).
    • This happens on every M5 unbind, since M5 never has a retirement witness. G15 and G16 pin the module for exactly this case; G17 doesn't.
    • Result: rmmod leaves firmware callbacks pointing into freed module code (root only).
  5. M5 work that SUBMIT accepts then fails with ENOTSUPP.
    • Where: queue/compute.rs:2419 (compute with a sampler heap) and m5_render_submission.rs:47 (some depth/MSAA renders).
    • Honeykrisp treats the failure as a lost device, and agx3c Mesa sets the sampler count for bindless samplers. Refuse these at validation.

Should fix

  • Queue cap per file (file.rs:1433, b1994bb3dbc): the cap is half the device limit per open file, so a second open() gets around it. It also limits Neo processes to 29 queues each.
  • Pool memory counted twice (freelist.rs:393): it's admitted as user memory, then held as kernel memory, so a 16 GiB pool uses 32 GiB of headroom.
  • Pool charge stays with the wrong client: when another client reuses a pool's storage, the original client is still charged for it.
  • Render kick rings writable in the upper half (kick.rs:610): they stay GPU-writable there (compute's alias is firmware-only), so ff0d367316b is incomplete under its own threat model. One metrics object is also mapped read-write into every client VM.
  • uAPI layout fragility: Mesa aurora-wip's 352- and 368-byte staged forms put fields at 336–368, where this kernel reads ray-query stages. It's safe only while features 24 and 25 stay unreported; the header should say they must never be reported again.
  • Display: the firmware buffer guard (afk.c:1899) lets unclaimed MMIO through to a cacheable mapping. A deferral on a T6050 external display now becomes permanent (dcp.c:5554). Two firmware-27 changes aren't gated: EPIC unit parsing on the T8140, and DPTX Activate failing on PHY errors.
  • Smaller items:
    • GET_PARAMS reports BOUNDED_AS_BUILD on M5, but the M5 validator rejects that flag.
    • Unused render-ring storage is never reused once its VM closes.
    • A released QoS entry that was busy at the time is never cleared.
    • The header still documents the G17P auxiliary allocation, which no G17P code reads.

Checked and sound

@funkzy
funkzy force-pushed the funkzy/t6050-gpu-on-integration branch from d078ca1 to 62cd1cc Compare November 7, 2026 00:52
funkzy pushed a commit that referenced this pull request Nov 7, 2026
@erikwb @funkzy
drm/asahi: Match the T6050 GPU by its G17S compatible
b042afb 
Bind the T6050 GPU through "apple,agx-g17s", the compatible its M5 Max
("apple,agx-g17c") and M5 Ultra ("apple,agx-g17d") nodes fall back to,
in place of "apple,agx-t6050", which no binding documents. The GPU's ID
registers still choose the board's configuration.

Signed-off-by: Erik Bourget <erik@ebourget.net>
[ onto #1012 rebased on integration/aurora 33bec40: conflicts in driver.rs only; the G17S entry probes through ProbeConfig::G17M5, the series' name for the M5 Pro/Max/Ultra entry beside integration's T8142 ProbeConfig::M5 ]
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
funkzy pushed a commit that referenced this pull request Nov 7, 2026
@erikwb @funkzy
drm/asahi: Match the T6050 GPU by its G17S compatible
6a76287 
Bind the T6050 GPU through "apple,agx-g17s", the compatible its M5 Max
("apple,agx-g17c") and M5 Ultra ("apple,agx-g17d") nodes fall back to,
in place of "apple,agx-t6050", which no binding documents. The GPU's ID
registers still choose the board's configuration.

Signed-off-by: Erik Bourget <erik@ebourget.net>
[ onto #1012 rebased on integration/aurora 33bec40: conflicts in driver.rs only; the G17S entry probes through ProbeConfig::G17M5, the series' name for the M5 Pro/Max/Ultra entry beside integration's T8142 ProbeConfig::M5 ]
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@funkzy
funkzy force-pushed the funkzy/t6050-gpu-on-integration branch 2 times, most recently from a07459c to 5b0f106 Compare November 7, 2026 02:36
funkzy pushed a commit that referenced this pull request Nov 7, 2026
@erikwb @funkzy
drm/asahi: Match the T6050 GPU by its G17S compatible
8b40458 
Bind the T6050 GPU through "apple,agx-g17s", the compatible its M5 Max
("apple,agx-g17c") and M5 Ultra ("apple,agx-g17d") nodes fall back to,
in place of "apple,agx-t6050", which no binding documents. The GPU's ID
registers still choose the board's configuration.

Signed-off-by: Erik Bourget <erik@ebourget.net>
[ onto #1012 rebased on integration/aurora 33bec40: conflicts in driver.rs only; the G17S entry probes through ProbeConfig::G17M5, the series' name for the M5 Pro/Max/Ultra entry beside integration's T8142 ProbeConfig::M5 ]
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@erikwb erikwb mentioned this pull request Nov 7, 2026
Merged
@funkzy
funkzy force-pushed the funkzy/t6050-gpu-on-integration branch from d30b165 to b1615e3 Compare November 7, 2026 09:11
@sithglan sithglan mentioned this pull request Nov 7, 2026
Closed
rolotrealanis98 added a commit to rolotrealanis98/m5pro-linux that referenced this pull request Nov 7, 2026
@rolotrealanis98
aurora/prs: GPU 27.2+ PR prepared (pr/m5-gpu-27.2 on #1012, 13 commits)
77518b8 
Branch pr/m5-gpu-27.2 34f2f5bb4d03 on aurora-silicon/linux#1012
(funkzy/t6050-gpu-on-integration b1615e3fca90, unchanged since the
integration). Commits 0001-0013 of kernel-27.2 with review-ready
messages; DCP 0014-0015 left for their own PR. Two code changes against
the integrated tree: the fwid KUnit test now expects V26C5035 for 27.3,
and Gpu::new() keeps refusing 27.2+ until the wiring commit so no
intermediate commit hands the firmware a half-converted graph (final
tree differs from gpu/integrated-27.2~2 only in the test).

Checks (all pass on the head) with README and store lists, PR body and
the #1012 comment. Not pushed, PR not opened.
This was referenced Nov 7, 2026
Draft
Merged
@dmitzsaz dmitzsaz mentioned this pull request Nov 8, 2026
Merged
This was referenced Nov 8, 2026
Merged
Merged
Open
Closed
DjDeveloperr and others added 7 commits November 8, 2026 12:03
@DjDeveloperr
drm/asahi: g17: M5: describe the M5 boards and refuse those without b…
14cdcf8 
…are-metal GPU tables

Add the M5 Pro/Max configuration (T6050) and its OF match, selected by
the ID registers. A G17 configuration now names its firmware protocol,
and the 26A428/25G83 graph tables become optional, since the M5 graph
carries its own. Probe refuses an M5 board that has no bare-metal GPU
page tables, and the M5 boot entry point stays closed until one does.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..15e1b3e4fa44 (3 commits); SPTM/APIF removed; adapted to integration's g17::Config, ProbeConfig and Firmware::Identified; original 6613f5ab7b7e, 1a021061f226, 15e1b3e4fa44 ]
[ rebased onto integration/aurora 33bec40: conflicts in driver.rs and hw/mod.rs only; the M5 Pro/Max/Ultra probe entry and function are named ProbeConfig::G17M5 and probe_g17_m5 beside integration's T8142 backend (ProbeConfig::M5, probe_m5); hw::t6050 sits beside hw::t8152 ]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
drm/asahi: g17: M5: give M5 VMs sparse tiles, render pool mappings an…
476cf7f 
…d context pins

Add the UAT pieces the M5 queues use: sparse-tile binds and their
zeroed and per-VM sink tiles, render pool mappings that move with a
pool identity, the metrics alias, execution-context pins and the M5
dynamic kernel ranges. On M5, a healthy last-job release skips the VM
drain.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..692d42fb35d7 (5 commits); SPTM/APIF removed; adapted to integration's mmu.rs (7.3 GPUVM, UatQuirks, ExecutionRoot, SG leases); comments and names reworded; M5 paths restored where the first rewrite lost them: one prepare_bind_object, with the sparse-tile bind; the G15/G16 adopted UAT (Uat::new_adopted_inner) sets m5: false, for integration's own config (defconfig + asahi.config), which builds G16 beside G17 and failed with E0063 without it; original 6613f5ab7b7e, e25ba8a6fb2b, 1a021061f226, f49e91b3f364, 692d42fb35d7 ]
[ rebased onto integration/aurora 33bec40: conflicts in mmu.rs only; the sparse_tile and table modules sit beside integration's t8152 one, and the sparse-tile map path follows integration's no-peer map preflight ]
[jq: dropped the per-VM metrics alias cache; each render now maps only its own metrics entry, per review]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
drm/asahi: g17: M5: build the M5 firmware's InitData graph
c75d823 
Add the M5 firmware's InitData layout and its graph builder, and let
InitData address the M5 bundle, private state, recovery views, effort
word and control ring at their M5 locations. Firmware events stay off
on M5 until its queues take submission, and the M5 effort word is
published as zero.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..77dc6eb34210 (5 commits); SPTM/APIF removed; adapted to integration's InitData (status_b and views fields) and fw::Variant; comments and names reworded; M5 paths restored where the first rewrite lost them: the M5 metrics binding; original 6613f5ab7b7e, e25ba8a6fb2b, 1a021061f226, f49e91b3f364, 77dc6eb34210 ]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
drm/asahi: g17: M5: back M5 render and compute pools with the M5 free…
b311814 
…-list layout

Add the M5 pool descriptor and free-list encodings, the render storage
demand they are sized from, and M5 render and compute pools beside the
existing ones. Render pool identities become leases that can move
between logical contexts, so idle storage is reused instead of
rebuilt.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..77dc6eb34210 (4 commits); SPTM/APIF removed; adapted to integration's freelist (capacity refusals, lower-window placement, per-context render pools); comments and names reworded; original 6613f5ab7b7e, e25ba8a6fb2b, cda233bc91f7, 77dc6eb34210 ]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
drm/asahi: g17: M5: install M5 queues and submit through the host com…
9b1f778 
…mand port

Add the M5 queue records, configurations and notifications, and the
host command port that installs a queue pair and submits work. On M5,
tiling, fragment and compute share the compute ring of each priority,
whose outer credits are claimed before either host port is written,
all under the device mutex.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..f49e91b3f364 (4 commits); SPTM/APIF removed; adapted to integration's InitData work publication and resource wait domains; comments and names reworded; M5 paths restored where the first rewrite lost them: the UAT's range for the compute kick rings and timestamps, the M5 control records, reports and statistics mask, the M5 firmware preparation, the fault window read, and the scheduler page from the retention pool; original 6613f5ab7b7e, e25ba8a6fb2b, 1a021061f226, f49e91b3f364 ]
[ rebased onto integration/aurora 33bec40: conflicts in channel.rs and reports.rs only; Reports::record() takes the family's tag mask beside integration's admitted flag, and the statistics drain keeps integration's per-drain receive time and cutoff ]
[jq: test-only; the report tests pass record()'s tag mask and index the second role at TAGS, so KUnit builds at this commit]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@funkzy @DjDeveloperr
drm/asahi: g17: M5: test that the M5 report mask counts tag 32 and re…
5c690ba 
…fuses tags past 63

M5's statistics mask adds tag 32 to the G17 family's, and record()
keeps 64 tags per role. The report tests checked neither, so a tag
counted under the wrong family's mask, or one past 63 indexing beyond
its role's samples, would have gone unnoticed.

A new case checks that tag 32 counts under M5's mask and not under
G17's, and that a tag past 63 is refused even with every mask bit set.
The invalid-tag case also tries tags 63 and 64.

Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
drm/asahi: g17: M5: accept the M5 render and compute program UAPI
395c06c 
Add the render and compute program resources, the shader-write,
stage-prefix and whole-attachment render flags, matrix and no-query
compute, and their feature bits. The command parser takes the resource
commands and the stage-prefix tail; validation applies the M5 command
set only where the firmware variant has it.

[ rebased onto integration/aurora: rewritten from t6050-gpu 6613f5ab7b7e..a507978ff411 (7 commits); SPTM/APIF removed; adapted to integration's UAPI numbering, ray-query stages and fw::Variant; the M5 UAPI flags and features in the UAPI header with agx3c Mesa's numbers, the stage-prefix fields appended to drm_asahi_cmd_render; interim forms until the render submission commit; comments and names reworded; M5 paths restored where the first rewrite lost them: VM_BIND accepts DRM_ASAHI_BIND_SPARSE_TILE; original 6613f5ab7b7e, e25ba8a6fb2b, bd4a3d7a0c97, 2f58522abec7, 2c5c77b6aaba, e393a52c7151, a507978ff411 ]
[ rebased onto integration/aurora 33bec40: conflicts in asahi_drm.h with integration's G18 UAPI; the M5 feature bit 30 and the render (21, 23, 24) and compute (16, 17) flags sit beside integration's G18 definitions, after its notes reserving them, and the bit-30 note names the defined bit; the stage-prefix fields are their own struct drm_asahi_render_stage_prefixes after the 448-byte struct drm_asahi_cmd_render (struct drm_asahi_cmd_render_m5, the same 480 bytes on the wire), as G18 carries its resources, so G18's 448/528-byte payloads and G15's size assert stay as integration has them; command.rs reads that tail ]
[jq: GET_PARAMS no longer reports BOUNDED_AS_BUILD on M5, whose command set refuses the flag; the scs_layout doc names M5, per review]
[jq: compute and render long-job allowance also counts M5's intersection tables, per review]
Signed-off-by: Diljit Singh <hey@djdev.me>
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
DjDeveloperr and others added 6 commits November 10, 2026 05:21
@DjDeveloperr
Merge #1404: validated M5 bring-up stack layer
5c1938f 
Preserve the source authors and the validated ordered M5 stack.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr
Merge #1422: validated M5 bring-up stack layer
cebabc0 
Preserve the source authors and the validated ordered M5 stack.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr
Merge #1436: validated M5 bring-up stack layer
607d797 
Preserve the source authors and the validated ordered M5 stack.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr
Merge #1435: validated M5 bring-up stack layer
5e1d606 
Preserve the source authors and the validated ordered M5 stack.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr
Merge current integration/aurora into the complete M5 bring-up stack
713a385 
Signed-off-by: Diljit Singh <hey@djdev.me>

# Conflicts:
#	drivers/gpu/drm/asahi/hw/t6041.rs
@DjDeveloperr
tools/asahi: bound the queue priority fixture before quota accounting
65bb111 
Keep the credential and priority gate extraction scoped before queue-share accounting, preserving the existing assertions and production behavior.

Signed-off-by: Diljit Singh <hey@djdev.me>
rolotrealanis98 pushed a commit to rolotrealanis98/linux that referenced this pull request Nov 10, 2026
@funkzy @claude @rolotrealanis98
drm/apple: dcp: Choose the firmware 27 method table by firmware build
290b7de 
Firmware 27.2 renumbered the IOMFB AP methods: the IOMobileFramebufferAP
methods moved up by 50, and set_create_DFB and vi_set_temperature_hint
by one. The UPPipe methods are unchanged. A DCP running 27.2 that is
sent a 27.0 tag panics ("link_rpc_lookup callback not found"); on T6050
the first one sent was A427.

Keep a method table per 27.x build and choose it at probe from
apple,firmware-compat ("27.0.0" or "27.2.0"). A firmware-compat with no
table is refused at probe with a message naming it, where a 27.x string
other than 27.0.0 was refused silently before.

The 27.2 tag of dfb_ready_query has not been seen in a call, so the
27.2 table has no entry for it and boot_5() does not send it to a build
whose table has none.

Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
[Rolando: resolved context conflicts with the afk_power_gen field and the
 panel_identity allocation that PR aurora-silicon#1012 added next to the new lines; the
 27.2 entry A478 (27.0 A428) is named iomfbep_set_brightness_correction, as
 PR aurora-silicon#1012's 27.0 table names A428, since dcpep_pipe_set_428 is not in its
 method enum; left dfb_ready_query out of the 27.2 table, where it was
 A385 by inference, and made boot_5() skip a query that has no tag]
Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com>
sithglan pushed a commit to sithglan/aurora-linux that referenced this pull request Nov 10, 2026
@erikwb @sithglan
drm/asahi: Match the T6050 GPU by its G17S compatible
b43b298 
Bind the T6050 GPU through "apple,agx-g17s", the compatible its M5 Max
("apple,agx-g17c") and M5 Ultra ("apple,agx-g17d") nodes fall back to,
in place of "apple,agx-t6050", which no binding documents. The GPU's ID
registers still choose the board's configuration.

Signed-off-by: Erik Bourget <erik@ebourget.net>
[ onto aurora-silicon#1012 rebased on integration/aurora 33bec40: conflicts in driver.rs only; the G17S entry probes through ProbeConfig::G17M5, the series' name for the M5 Pro/Max/Ultra entry beside integration's T8142 ProbeConfig::M5 ]
Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
@DjDeveloperr
DjDeveloperr merged commit c54454d into integration/aurora Nov 10, 2026
5 checks passed
@RyanTheTide RyanTheTide mentioned this pull request Nov 11, 2026
Merged
This was referenced Nov 11, 2026
Merged
Merged
This was referenced Nov 11, 2026
Merged
Merged
Merged
This was referenced Nov 11, 2026
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Closed
Merged
rolotrealanis98 pushed a commit to rolotrealanis98/linux that referenced this pull request Nov 12, 2026
@funkzy @claude @rolotrealanis98
drm/apple: dcp: Choose the firmware 27 method table by firmware build
61a1fd0 
Firmware 27.2 renumbered the IOMFB AP methods: the IOMobileFramebufferAP
methods moved up by 50, and set_create_DFB and vi_set_temperature_hint
by one. The UPPipe methods are unchanged. A DCP running 27.2 that is
sent a 27.0 tag panics ("link_rpc_lookup callback not found"); on T6050
the first one sent was A427.

Keep a method table per 27.x build and choose it at probe from
apple,firmware-compat ("27.0.0" or "27.2.0"). A firmware-compat with no
table is refused at probe with a message naming it, where a 27.x string
other than 27.0.0 was refused silently before.

The 27.2 tag of dfb_ready_query has not been seen in a call, so the
27.2 table has no entry for it and boot_5() does not send it to a build
whose table has none.

Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
[Rolando: resolved context conflicts with the afk_power_gen field and the
 panel_identity allocation that PR aurora-silicon#1012 added next to the new lines; the
 27.2 entry A478 (27.0 A428) is named iomfbep_set_brightness_correction, as
 PR aurora-silicon#1012's 27.0 table names A428, since dcpep_pipe_set_428 is not in its
 method enum; left dfb_ready_query out of the 27.2 table, where it was
 A385 by inference, and made boot_5() skip a query that has no tag]
Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com>
@satchlj satchlj mentioned this pull request Nov 12, 2026
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@RyanTheTide RyanTheTide RyanTheTide left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@funkzy @TripleU613 @DjDeveloperr @RyanTheTide @erikwb