Repository navigation
omacom sync: G15 (M3 Pro/Max) backend, PB growth, stamps, raw GPU stats - #771
Closed
RyanTheTide wants to merge 47 commits into
Closed
RyanTheTide wants to merge 47 commits into
RyanTheTide wants to merge 47 commits into
Conversation
…rowth ledger The PB ledger only knows the posted count. For backing that is allocated after a reply instead of before it, the ledger also has to know how many blocks are backed, grant a request only from those, and start over at a re-initialization without forgetting the backing. Add `backed` to the ledger. `accept()` now returns an answer: - a grant, clipped to the backed blocks above the posted count; - a refusal at the maximum (the refusal bound is unchanged); - a wait when no backed block is left: the request keeps its counter and can be accepted again once more is backed. `reinit()` returns the posted count to the initial size and keeps the backing; Pools::init() uses it instead of a new ledger. The growth chunks that back_pb() allocates before an answer are now 128 blocks (16 MiB) instead of 32. answer_request() copies the backed count into the ledger after back_pb(), so no request waits yet. Host tests (pools/growth.rs, run by the asahi-g15 selftest): the clamps and the producer bound over the constructor's boundary values with the heap backed, growth to the maximum and re-initialization, and grants clipped to the backing, with waits that keep the counter. The ledger is shared by the T6030 and the T6031; this is untested on the T6030. The growth harness follows the chunk size and the ledger reset. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 9414805) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…h a reserve back_pb() allocates and maps the backing of a growth request before the answer, while the firmware waits for it. The allocation has no time bound (shmem pages with __GFP_RETRY_MAYFAIL), and a failure leaves the request unanswered until the host deadline. Keep one chunk of backed blocks in reserve above the posted count and back the next chunk after the replies of a poll pass: - the heap is backed in chunks of 128 blocks (16 MiB), each a gpu_backing() object at its fixed client GVA (chunk_gva()); - when the GPU starts, the chunks of the initial posting and one reserve chunk are backed (9 with the initial 1024 blocks); - answer_request() grants only from backed blocks; while fewer than 128 remain above the posted count, refill_backing() backs chunks at the end of answer_growth(), after every reply of the pass; - with the reserve dry (an allocation failed), a request waits: it goes back to the head of the queue with its counter and is answered by a later pass once a chunk is backed; - a pending re-initialization backs nothing while no render is published; a render published before it (the flights behind a fragment kill) is still backed, or its requests would wait until the deadline. A compute-only flight gets none: it cannot ask for growth. Mapping stays per VM and before the VM can reach a block. A VM maps every chunk it lacks at the start of its prefix's publication (map_pb(), with its one-VM check), and a chunk backed by a refill is mapped into the VM of the flights before the ledger counts it. If that mapping fails, the chunk is dropped again and the next pass retries. The aliases are held in the VM's own heap list (VmState::map_heap()), which keeps the object of each alias. A chunk whose object changed is unmapped and mapped again, and aliases past the backing are dropped. back_pb(), running_vm() and the per-VM count are removed: no grant can name a block that the running VM has not mapped. This applies to the T6030 and the T6031, which share this code; it is untested on the T6030. The debugfs pb: line appends waits and refills. The growth harness now runs answer_growth(), answer_request(), map_pb(), refill_backing() and the VM heap-mapping bodies. Its new cases: - the start backing; - allocation only after the pass's replies; - a dry reserve that makes a request wait and keeps its order; - a failed refill map that drops the chunk; - a pending re-initialization with no flight, with a compute-only flight, and with a render published before it; - catch-up at publication, including a partial one. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 7eae5b0) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The initial posting is 1024 blocks (128 MiB), with 9 chunks (144 MiB) backed when the GPU starts. On the J516C, an idle desktop with a 64-block start stayed at 64 posted blocks (8 MiB), and growth is a round trip of 1-2 ms per ten blocks. Post 64 blocks at (re)initialization by default, settable with g15_pb_blocks (64..4095, read-only after boot). The PB then needs two chunks (32 MiB) when the GPU starts: the posting and the reserve. tuning::PB_BLOCKS is removed. g15_pb_max_blocks, the firmware's growth maximum, is still raised to at least the initial posting; its help text no longer says that the 512 MiB heap is allocated in any case. This applies to the T6030 and the T6031, which share this code; it is untested on the T6030, and g15_pb_blocks=1024 restores the old start. The zero-words harness pins hw.rs whole; its hash is refreshed, and its T6030 configuration module stays pinned to the original bytes. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit b91c280) [ryan: read g15_pb_blocks by value, as the Linux 7.3 module parameter API returns it, in the driver and in the host model] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Posted blocks never come back while a PB lives. The firmware recycles pages inside its own pool and the records give the host no view of it, so the posted count only grows until a recovery re-initializes the PB. On the J516C one dEQP case takes about 1200 blocks past the firmware's maximum each time it runs. The second run of one dEQP list exhausted the 512 MiB heap, and the GPU fail-stopped after the refusals. Re-initialize the PB when the engine has had nothing published and nothing pending for g15_pb_idle_ms (1000), with more than g15_pb_reclaim_blocks (1024) posted: - the next render prefix takes the re-initialization path of a recovered abort (fresh lists and manager, InitBM of the initial blocks), with no halt; - with g15_pb_reclaim 2 (the default), the chunks above those of the initial posting and the reserve are freed at once and unmapped from every VM of the registry; a VM that publishes later drops its stale aliases first (VmState::map_heap()); a chunk counts as freed only once every VM's alias of it is unmapped; - g15_pb_reclaim 1 re-initializes only, 0 never; - nothing is re-initialized when nothing grew since the initialization (posted == initial), whatever g15_pb_reclaim_blocks is. The idle clock is noted at the end of every poll pass and publication and when a job arrives. The check runs in idle poll passes and when a job arrives at an idle engine, before its publication, because an idle poll is not re-armed. This applies to the T6030 and the T6031, which share this code; it is untested on the T6030 (g15_pb_reclaim=0 turns it off, and g15_pb_blocks=1024 restores the old start). The debugfs pb: line appends reclaims and freed chunks. Host tests: the idle clock, the reclaim test of the ledger, a heavy scene freed and refilled, and (growth harness) a VM that maps chunks freed and backed again from their new objects. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 54941fe) [ryan: read the three reclaim parameters by value, as the Linux 7.3 module parameter API returns them] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…undary The idle reclaim needs g15_pb_idle_ms without work. Heavy scenes started back to back, each by a new client a few hundred ms after the last, never reach it. On the J516C three such scenes of about 1420 blocks each ran the heap to its maximum, and the fourth hung the GPU into fail-stop. Re-initialize also after 50 ms idle with more than half the maximum posted and grown since the initialization (an initial posting above half the maximum is not drained). 50 ms is longer than the gaps between one client's renders. On the J516C a re-initialization with no idle time faulted at the heap base, at a client switch, the second time in a row with no recovery between; with 50 ms of idle none faulted, also between two renders of one client 60 ms apart. This path keeps the backing, so the next scene does not allocate it again. The idle reclaim now also runs when more chunks are backed than the posted blocks need (free_due()), so backing kept this way is freed even if the next client posts below g15_pb_reclaim_blocks. With no render after the client boundary, the re-initialization stays pending, and with g15_pb_reclaim 2 the check frees the backing above the kept chunks once the engine has been idle for g15_pb_idle_ms (a recovery's pending re-initialization still stops the check). This applies to the T6030 and the T6031, which share this code; it is untested on the T6030 (g15_pb_reclaim=0 turns it off, and g15_pb_blocks=1024 restores the old start). Host tests: back-to-back heavy scenes never reach the maximum and keep their backing, and kept backing is freed at the next long idle. The growth harness also runs reclaim_check(), free_backing() and note_idle() over a clock: a heavy client that exits with nothing rendered after it is re-initialized after 50 ms and its kept backing freed after the long idle, its posted count kept until the InitBM; at level 1 the backing stays; a recovery's pending re-initialization frees nothing; nothing grown, nothing is re-initialized. The reclaim keeps the posted count until the next render's InitBM, as the driver does: the same client rendering again after 60 ms grows again from the kept backing with nothing allocated, after 1.1 s over freshly backed chunks mapped before they are posted, and a compute-only submission between the reclaim and the InitBM maps, backs and posts nothing. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 59aced9) [ryan: the host model reads the reclaim parameters by value, as the Linux 7.3 module parameter API returns them] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…ecords The CDM gate walks a compute stream from its base through its links and refuses it after 8192 records. A legitimate stream can be longer. On the J516C, the three dEQP-VK multi_draw.mosaic cases with max_draws and tessellation (1024 tessellated draws, several launches and barriers each) were refused: "rejecting CDM record budget record", then EINVAL from the submit. The gate is shared by the T6030 and the T6031. It already admits at most 64 links, and Mesa's encoder links to a new 64 KiB block when one fills, so a stream that fits the link budget is at most 65 blocks. Bound the walk by the bytes of its records instead: at most (64 + 1) * 64 KiB (4160 KiB) of stream, whatever the mix of 4-byte barriers and 24- to 40-byte launches. A stream without TERMINATE still ends at that bound or at the link budget, so the walk stays bounded: at most 1064960 record reads of 4 bytes. A walk does not check again the last page it found good, for a program or for an indirect launch's 12 argument bytes, and it makes at most 16384 page checks; one more is refused as "CDM page check budget". The walk holds no device lock: the queue's mutex covers the SUBMIT, and the VM's lock is taken per check (about 4 us on the J516C) and per 256-byte read (about 5 us). Without the cache and the bound, a stream of 24-byte indirect launches with distinct argument pages made one check per launch: about 0.8 s per compute command and about 51 s per 64-command SUBMIT. Now it is at most about 149 ms per command and about 9.5 s per SUBMIT. Mesa's indirect arguments move to a new page every few dispatches: 40000 dispatches made 41410 checks in 224 ms before and 6848 in 94 ms after, and the largest stream the link budget admits (47000 dispatches) makes 8047. The 608 dEQP-VK multi_draw.mosaic max_draws with_tess cases pass. Host tests (asahi-g15 selftest): 10240 barriers and a terminator are admitted; a terminator in the last word of the budget is admitted and one past it refused; a stream of the budget without a terminator is refused; 64 links are admitted and 65 refused; 1000 launches in one argument page make 2 page checks; a program and 16383 argument pages are admitted and one more page is refused without its check; 170000 launches over 16 argument pages are admitted with 17 checks. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit ae93621) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The G15 backend loads the T6031 board images with kernel::firmware (g15/board/blob.rs), which exists only with CONFIG_RUST_FW_LOADER_ABSTRACTIONS. DRM_ASAHI_G15 does not select it: the symbol comes only from APPLE_AOP, APPLE_SEP or nova-core, so a configuration without them fails to build the driver. Select RUST_FW_LOADER_ABSTRACTIONS from DRM_ASAHI_G15. It depends only on RUST, which DRM_ASAHI already requires, and selects FW_LOADER. Built with APPLE_AOP and APPLE_SEP off: the option resolves to y and drivers/gpu/drm/asahi builds. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit c562b82) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…out new work The reclaim check runs in poll passes and when a job arrives, but an idle engine runs no poll pass: the pass that retires the last flight is not re-armed. On the J516C, a client-boundary re-initialization kept 23 chunks (368 MiB) for a client that then posted 264 blocks. With no new job they were still held 15 s later, and only the next job's arrival freed 21 of them. When a poll pass ends with the engine idle, compute how much longer the engine must stay idle before the reclaim check would act (Ledger::reclaim_delay(): the idle reclaim at g15_pb_idle_ms, the free of kept backing at level 2, or the client-boundary re-initialization). Then queue the poll work for that delay. The pass it runs takes the device lock and runs the idle path: note_idle(), then reclaim_check(). Nothing is armed while busy, while a recovery or its re-initialization is pending, or when nothing can become due. While a reclaim's re-initialization is pending (a client-boundary one keeps the backing), the poll is armed for the rest of g15_pb_idle_ms at level 2 (Ledger::pending_free_delay()), not for the expired 50 ms, so the check frees the kept backing of a heavy client that exits with no render after it. A job's arrival re-arms the poll work for its publication, which replaces the expiry. The delay mirrors the checks, also in requiring growth since the initialization. This applies to the T6030 and the T6031, which share this code; it is untested on the T6030 (g15_pb_reclaim=0 turns the reclaim off, and g15_pb_blocks=1024 restores the old start). Host test (pools/growth.rs): over levels, floors, idle times, posted counts and backing, the delay is the first idle time at which reclaim_due(), free_due() or drain_reinit_due() holds. None of them holds one nanosecond before it, and none ever holds when there is no delay. The J516C case gives g15_pb_idle_ms at level 2 and nothing at levels 0 and 1. The growth harness also runs reclaim_delay_ns() and drives the idle poll work as poll.rs arms it: a heavy client that exits with nothing rendered after it wakes the poll at 54 ms (the re-initialization) and at 1004 ms (the free), and nothing is armed after; an idle reclaim arms nothing once its re-initialization is pending; nothing is armed at level 1, for a recovery's re-initialization, or when nothing grew. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit aa142ee) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The boot loader enables the T6030/T6031 GPU node only when its chosen.asahi,t603x-gpu setting is on. With the setting off, as the installed m1n1 configuration of a J516C can have it (chosen.asahi,t6031-gpu=0), the node stays disabled. The adapter then never probes, and the kernel log gives no reason why there is no native G15 GPU. At module activation, log one line when /chosen carries asahi,t6031-gpu or asahi,t6030-gpu and the matching GPU node is disabled. The line names the node and the property's value. Nothing else changes; machines without the property log nothing. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit a089fd0) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The T6030 PMP device-tree test that follows compiles the board trees with
this kernel's scripts/dtc/dtc and reads the result with fdtget. Build dtc
next to the kconfig tool the runner already builds, pass it to a test as
'{dtc}', and let --dtc name an existing one. The CI job installs
device-tree-compiler when fdtget is missing.
Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The static PMP nodes block the display gate's overlay and leave G15 deferred on M3 Pro. Keeping either the static DART or mailbox would still conflict with the overlay. Guard all four nodes with APPLE_USE_PMP, matching the existing alias and consumer guards. Check the default and static PMP nodes in CI. Assisted-by: Codex:GPT-6 Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit 2c916d2) [ryan: register the test in tools/asahi/run-host-tests.py, with the runner's built dtc, instead of omacom's tools/aurora-ci/host-tests.json] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The DT uses names such as uat-ttbs@10, but of_find_node_by_path() requires an exact match and misses them. Use of_node_name_eq() on /reserved-memory children. Require one matching owner and keep the existing range and property checks. Extend the host test to cover unit addresses and duplicate owners. Assisted-by: Codex:GPT-6 Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit 8b0cbd5) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
A started G15 firmware session cannot be stopped, so boot::start pins the module before its first firmware-visible write and never drops the reference. The pin used __module_get(), which increments the count unconditionally, even after an ordinary rmmod has passed its reference check in try_stop_module(). The first start can run while the module is LIVE. Activation attaches synchronously during module init, but a probe deferred for the PMP supplier, or attached asynchronously with async_probe, runs later from the deferred-probe or async worker. If an rmmod has passed its reference check by then, module exit unregisters the driver, which waits for the in-flight probe to finish starting the firmware, unbinds the device and frees the module under the live session and its RTKit callbacks. Take the reference with try_module_get() before RETAINED is set and before anything firmware-visible. Once removal has begun this fails with ENODEV and leaves the firmware untouched, cleaned up as for a failed self-check: the cached-class objects are forgotten, the PMP vote is released and the session stays unretained. A caller that loses the race to set RETAINED drops only its own reference. The policy is in g15/retain.rs so the asahi-g15 host runner covers it: a refused pin marks nothing, the first pin is kept and later calls take nothing, a lost race drops only its own reference, and barrier-synchronized concurrent pins leave exactly one reference. Generated-by: LLM Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 095edba) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The J516C hardware record took 32 words from asahi/t6031-j516c-board.bin, a per-machine file that installs do not ship, and the driver compared the three images it built against the file before starting the firmware. A J516C without the file could not start the GPU. Take those 32 words from sources every J516C has, as the T6030 path does with its templates: - The six GPU sensor rows (18 words) are entries of the ADT's /arm-io/aon-ptd ptd_data_table, which the boot loader already exports (the phram "adt" region the T6030 path reads): the "RT" entries of kind g (four), r and f. The device tree does not carry the table. Any other count is refused. - The maximum power, the relative powers of DVFS states 1..7 and the MTR fast-die and alarm masks (14 words) are not in the device tree or the ADT. They become the J516C reference machine's values (board::record::J516C), as the T6030 templates carry their reference machine's. The device tree's operating-point powers stay unused; they are a boot-loader stand-in. hw::Board::Blob becomes hw::Board::DeviceTree(&Reference): no firmware request, no file digest, no file cross-check. The firmware identity pins and the apple,j516c machine match are unchanged. board/blob.rs and the RUST_FW_LOADER_ABSTRACTIONS select go. The off-tree J516C fixture test now builds the record from a saved device tree and ADT with the reference words and checks it against the machine's own record: byte-identical except the 42 words shown unneeded earlier. g15-zero-words-tests.py follows the new sources (14 reference + 18 sensor row + 42 zero words = the original 74); its hw.rs and prepare_board() pins are refreshed for the Board change, the T6030 arms are unchanged. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit aeffd0e) [ryan: our G15 Kconfig has no DRM_ASAHI_UAT_ADOPTION select; the zero-words harness keeps our docstring history and pins our hw.rs bytes] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The handoff test compiles GpuAdt and the T6030 ADT parser from adt.rs on the host. GpuAdt now carries the T6031 sensor rows, sized by board::record::SENSOR_ROW_COUNT, which the generated source did not define, so the test no longer compiled. Take that production constant from board/record.rs into a generated record module, and hash board/record.rs with the other sources in the receipt. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 23a7bd1) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Log the SHA-256 of the hardware record built from the device tree, the ADT sensor rows and the reference words, as the T6030 templates path does for a record that differs from its reference. A report from another J516C then shows at once whether its record matches. Also bring the prepare_board() comment up to date: the T6031 arm no longer has a digest to check or a firmware file to request. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Naeem Malik <malik2015naeem@gmail.com> (cherry picked from commit 79f7891) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Include zero in the firmware stamp cycle. Keep absent dependencies and completed progress separate from wrapped zero stamps. Generated-by: LLM Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit d82144ad56a8ac7e75d74294e051683efccbb2a0) Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 7ccdfe8) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Idle VMs must not reserve hardware ASIDs. Bind without waiting at publication, release at successful retirement, and retain failed published jobs. Logical VM creation is limited by memory rather than slot count. Generated-by: LLM Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit 8525dd8e380a708356ec1ffaef0bbdf266cb328b) Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit bb3ce59) [ryan: keep our two M4 handoff checks in Uat::bind_inner and the by-value robust_isolation read of Linux 7.3] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Each range check and stream read relocked the VM and all external BOs. Share one exec lock across validation, preserving permission checks and cache maintenance, and propagate acquisition errors. In profiled 10-second vkQuake runs, kernel CPU time falls from 3.30 to 1.01 seconds. The bounded validation walk holds VM and external BO reservations together, so other users of shared buffers can wait. Generated-by: LLM Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit 610cc54ad4987dd4bf8948d44e1161b1a260b0e4) Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 289bcca) [ryan: our tree has no CONFIG_DRM_ASAHI_UAT_ADOPTION: build VmReadGuard, read_lock() and read_user_locked() with G15 or G16, the configurations that build Vm::read_user(), so the G16 kernel keeps compiling] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The RTKit AGX vote does not set the PTD power request. PMP receives GPU performance-state updates but ignores its bandwidth demand without that request, leaving memory at its idle floor. Report AGX power after firmware and backend initialization. An earlier report is acknowledged but does not enable bandwidth scaling. Reassert it so a failed early power-off cannot leave a stale report across startup. Use the report driver's lock and checked soc-device table, and clear the report before releasing the vote. Other SoCs keep their existing path. With Mesa unchanged, the packaged kernel takes vkQuake from 104.5 to 372.5 FPS at 1920x1080 and compute-copy bandwidth from 32.7 to 136.3 GB/s. Tested on an M3 Pro J514S. Generated-by: LLM Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> (cherry picked from commit 8824dd6a7aaa2b302ca7b3a77c2022bacc0fbdc8) Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 9bb7476) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Carry the host models forward with the publication-time binding API: provide Job::slot and a separate VM identity for PB growth, and pin the hw.rs golden after proving the only change removes MAX_VMS and its comment. Exercise production bind, release, completion and prefix-admission bodies with explicit modeled slot allocation. Cover retry on slot exhaustion, binding reuse, successful release, failed-job reference lifetime and an append failure after publication, with five additional runtime mutants. Model the T6030 PMP readiness service in the retention harness. Cover readiness failure with and without orphan allocation, successful startup, and exclusion on other platforms, with two additional runtime mutants. Retain the existing failure and removed-fix controls. Clarify last-reference versus fail-stop retention in the ownership comments and format the carried compute match arm. These edits change no production admission, firmware identity, power policy or submission behavior. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 9d5fd8f) [ryan: keep our ENOENT, unobserved_teardown and old-control digest additions in the host tests, and pin our hw.rs bytes] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The complete tools job found two more host fixtures that predate the T6030 PMP export changes. display26 lacks OF compatibility lookups and GFX-report service definitions; the supplier harness lacks the new report-check and report-update boundaries. Keep display26 on its modeled J613 platform and fail explicitly if it reaches a T6030 report. Model the supplier harness report service under the existing lock, exercise a forwarded report-check error, and require that power-on does not start bandwidth tracking before backend READY. Add a runtime mutant that drops the report-check error. Retain the existing configuration, supplier, readiness and serialization mutants. The production report transaction remains covered separately by the G15 PMP-vote selftest. No production code changes are made here. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> (cherry picked from commit 5af4959) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
T6031 was kept out of the G15 autoload table until it had an admission gate ordering its first firmware start after the native display, as T6030 has through its display and PMP links. Give drm/apple one ready/defer helper with a publication slot per SoC display subsystem, published after DRM registration and client setup and withdrawn before unbind, and export apple_drm_t6031_link_device() beside the T6030 one. T6031 admission calls it after the J516C machine check and before anything else: it defers until that display is published, so a boot that leaves the display disabled keeps the GPU waiting (logged once) rather than starting it. T6030 is unchanged and T6031 gains no PMP vote. Then add apple,agx-t6031 to the alias table. A manual load on J516C now waits for the native display as well. The GPU still needs the m1n1 GPU handoff, the opt-in native display (apple_t6031_display.enable=1) and the pinned board file; this change provides none of them. tools/asahi/g15-display-order-tests.py runs the actual bodies on host models with mutants and is registered in tools/aurora-ci/host-tests.json. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 8ea9a72) [ryan: use the Linux 7.3 of_device_table! form without ID info for the autoload table; register the test in tools/asahi/run-host-tests.py instead of omacom's tools/aurora-ci/host-tests.json] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
… slots The T6030 display publisher and link now go through the shared G15 display slots and link helper (8ea9a72). This suite's anchors and C fixture still named the removed apple_t6030_display_publish/withdraw and their lock, so it failed at its first source-order check. Extract the slot, publish and withdraw functions, the shared link helper and the T6030 wrapper, and give the fixture the shared lock and the T6031 slot. The unrelated-display control now uses a non-G15 display subsystem. A new case checks that a published T6031 display takes its own slot and never satisfies T6030 admission. The seven mutants are carried over to the shared code; wrong-gpu keeps the helper's parameter used so that it still builds. One more mutant maps the T6031 slot onto the T6030 one. Every mutant builds and is killed. Production code is unchanged. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit c69f2b1) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…516C The T6031 native display gate ran only with apple_t6031_display.enable=1 on the kernel command line, so a J516C whose boot loader hands the display over still stayed on the boot framebuffer, and with it the G15 GPU, which waits for that display before its first firmware start. Make the T6031 switch tri-state: unset, the native display is requested on the J516C (root compatible apple,j516c) and not on the other T6031 boards. An explicit apple_t6031_display.enable=0 or =1 wins on every T6031 board, and a value kstrtobool() rejects preserves the previous explicit choice, or the board default when unset. The request is resolved once in gate_run(), before the existing checks. The handoff marker, the boot loader's PMP values, the PMP image, the power layout and every refusal after them are unchanged, so a J516C without a complete handoff keeps the framebuffer and the GPU keeps waiting. T6030, T8122, J514C and T6034 behaviour is unchanged. Update the help, the device tree comment and the G15 wait message, which said that =1 is always needed. The KUnit suite saves and restores the switch and the default board, checks the switch values and their resolution, and runs the default-board path through gate_run() with the test tree's own root: on by default, off with =0, and untouched without the handoff marker. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 41aa66d) [ryan: applied to our drivers/soc/apple/display-gate.c, display-gate-test.c and APPLE_DISPLAY_GATE, the renamed T6030 gate] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
A T6031 GPU starts its firmware only after the native display is published, so apple_t6031_display.enable=0, or a display that never comes up, also keeps the GPU off for that boot. The Kconfig help and the display gate's comments described the switch as display-only. Say that it also keeps the GPU off. The only G15 line while the GPU waited was the one for a display node this boot did not enable. An enabled display that is not published yet, because its DCP refused or failed to bind or it has not registered, left the GPU deferred with nothing from G15. Say once that the GPU is waiting for the display to come up. Return values and the wait itself are unchanged. The display-order host controls now expect that line, once, for an enabled but unpublished display, and a new mutant that drops it is caught. Generated-by: LLM Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit ca6c77a) [ryan: applied to our drivers/soc/apple/display-gate.c and APPLE_DISPLAY_GATE, the renamed T6030 gate] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The T8122 runtime builds g15/hw.rs without the G15 backend, which has no
board module, so DRM_ASAHI_M3_T8122=y with DRM_ASAHI_G15=n fails:
error[E0433]: failed to resolve: could not find `board` in `super`
--> drivers/gpu/drm/asahi/g15/hw.rs:54:32
Only the G15 backend builds device-tree board data.
Fixes: aeffd0e ("drm/asahi: g15: t6031: build the J516C board data without a board file")
Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja>
Assisted-by: Claude:claude-opus-5-5
(cherry picked from commit 6c98368)
[ryan: pin our hw.rs bytes in the zero-words harness]
Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Only the G15 backend binds VMs at publication. With DRM_ASAHI_M3_T8122=y and DRM_ASAHI_G15=n, W=1 warns that Uat::try_bind is never used. Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit 88e3cc7) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Only the G15 command checks use it. With DRM_ASAHI_M3_T8122=y and DRM_ASAHI_G15=n, W=1 warns that it is never used. Signed-off-by: Eryk Wieliczko <eryk@wieliczko.ninja> Assisted-by: Claude:claude-opus-5-5 (cherry picked from commit f5d7233) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
retry-running-teardown assumes its stop thread has entered cancellation within a fixed 30 ms sleep. If the thread is not scheduled in that window, the control aborts before teardown runs. It also reads cancel_waiting without the fixture mutex. Broadcast the fixture condition when cancellation starts and wait for that event under the mutex, with a bounded two-second deadline. Keep the retry worker paused until the teardown assertions have run. A missing cancel still fails rather than timing out the entire suite. Fixes: 71700a1 ("net: thunderbolt: retry receive refill after allocation failure") Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Generated-by: LLM (cherry picked from commit a9fa0bb) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The display gate refuses any existing PMP or report compatible anywhere in the tree, including disabled nodes. The DT control only checks four names under /soc, so renamed or nested nodes can pass it and still block the runtime PMP overlay. Walk the whole default-profile tree and reject either compatible in any entry of each compatible string list. Keep the existing static-profile node and alias checks. Compare case-insensitively, as the OF lookup does. Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Generated-by: LLM (cherry picked from commit 212c155) [ryan: drop the Link to the omacom review discussion] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The 14-inch M3 Pro (J514S) boot chain loads the same G15 B0 firmware image as the J516S: TEXT 0x5c000, DATA 0x114000, GKTS marker 0x58e88 and TEXT sha256 da26eccab1f8598da80c855eca916520406d1d0670f1d470e79bb9b02209db53. The pinned row names only apple,j516s, so on a J514S the build is refused and the GPU only starts with the g15_accept_text_prefix bring-up override. Add the same build as a J514S row. Rows still pin on the machine they name; nothing changes on the J516S or on other machines. Extend the maintained-handoff host test to check both rows. Measured on a J514S (macOS 14.8.3 stub, 7.2.11 on integration/aurora 937b727): the override log line reports the identical size, marker and digest, and the GPU has run with that build since 2026-10-23. Signed-off-by: Jeppe Bylov <jeppe@bylov.net> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 6523818174f3750334d3f4a403e5b59035931dd8) (cherry picked from commit 9ce2cf3) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The J514S B0 firmware row changes the hw.rs file and its independently pinned T6030 module. Derive both hashes from the current integration tree plus exactly the reviewed 15-line firmware-table insertion. Keep the extraction, assertions and mutation controls unchanged. The maintained-handoff and zero-word mutation suites pass with the new row. Removing the row, changing the J516S digest, or editing outside the module still fails the source guards. Signed-off-by: Chris Kearney <ckearney@pm.me> (cherry picked from commit d777cc2) [ryan: pin our hw.rs bytes; the T6030 module pin is omacom's, as our module carried the same original bytes] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The stats channel keeps the firmware words verbatim in a new raw snapshot: every message kind keeps its last sample, a sample counter and the monotonic capture time. No unit is assumed, nothing is scaled and no metric is derived. The snapshot is exported read-only as `asahi_stats` in the DRM device debugfs directory, format tag `asahi_stats_v1`. The interpreted `agx_stats` sysfs export is unchanged, and the raw recording is not gated by the stats_export parameter. The G17 and M3 backends have no stats channel decoder, so they expose no raw file, like their sysfs export. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com> (cherry picked from commit ecc2211) [ryan: our driver has no T8122 probe; the debugfs entry is removed by drm_dev_unregister() before the registration data that owns the snapshot is dropped, so the driver data keeps no extra reference; read stats_export by value as on Linux 7.3] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The raw firmware statistics export had no format document. This adds the ABI entry for the asahi_stats_v1 text format: file location, line order, fields, and what is not established. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com> (cherry picked from commit 2d2ac34) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Counts restart when the driver binds the device again, so say that instead of since boot. Use the public maintainer name in Contact. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com> (cherry picked from commit c59f572) [ryan: Contact is the maintainer named in our other Aurora ABI files, not omacom's] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Without CONFIG_DEBUG_FS drm_debugfs_add_file() is a static inline stub, so bindgen emits no binding and the Rust build fails. The KUnit configuration has debugfs off, which is how the CI KUnit job found it. Create the file only when CONFIG_DEBUG_FS is set. Signed-off-by: Joshua Warren <816217+joshuaswarren@users.noreply.github.com> (cherry picked from commit ad967fa) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The asahi_stats format test came in as drivers/gpu/drm/asahi/tests/ test_asahi_stats_export.py, which nothing runs and which has no SPDX line. Move it to tools/asahi/asahi-stats-raw-tests.py, read stats_raw.rs from the tree root, add the SPDX line and register it in tools/asahi/run-host-tests.py so it runs with every host test pass. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The TA stamp of render ordinal n is stamp_seed(TA_SEED, n): it steps by 0x100 and wraps after 0x860000 renders, about six hours of desktop. With the stamp_seed() from before commit 7ccdfe8 ("drm/asahi: wrap G15 stamps through zero"), which skipped zero and went from 0xffffff00 back to 0x100 there, the firmware stopped at render 8781824 with "DAG: Non Sequential Stamp Updates seen ... stampValue 0x100" and the GPU was lost until reboot. Since that commit the stamps wrap through zero; whether the firmware takes that wrap has not been tried. Add an offset to the render ordinal used for the TA/FS stamps and, when g15_stamp_reseed_margin is set, renumber both stamps from their seeds at the first publication with nothing in flight inside that margin: write the seeds to the user and firmware stamps, reset the engine targets and move the offset so the next render counts as ordinal 1, as after boot. The offset is taken modulo the 2^24 ordinals after which stamp_seed() repeats (STAMP_PERIOD). The stamps then never reach the wrap. g15_stamp_base starts the count near the wrap, to test this in seconds instead of hours. Both parameters default to 0, which keeps the stamps exactly as before. Tested on a J516C, together with the next commit, on integration/aurora with the earlier stamp_seed() and the offset taken modulo its period of 0xffffff ordinals: from g15_stamp_base 2000 renders before the wrap with a margin of 1000, the stamps were renumbered at render 1000 and 3003 renders retired; in desktop use, one boot renumbered at renders 8681824 and 17363648. On this base, modulo 0xffffff would give the render after the first renumbering ordinal 0, whose targets the seeds already meet, and the one after the second ordinal -1, a TA target below the seed. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com> (cherry picked from commit 541f3e4) [ryan: read the two stamp parameters by value, as the Linux 7.3 module parameter API returns them] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Renumbering only happens at a publication with nothing in flight. A client that keeps the GPU busy (no vsync) can keep a flight in the air through the whole margin, and the TA stamp would then wrap as before. Inside the margin, publish nothing behind a flight, so the flights drain and the next publication renumbers while idle (once every ~8.7M renders with a margin of 100000). Also clamp a non-zero margin to at least one prefix of renders, so that the last prefix published outside it cannot cross the wrap, and to at most half the stamp range, so that it cannot renumber on every publication. Found while reviewing the previous commit, with a model of prefixes of 1-8 renders: a fully overlapped client wrapped 199/199 times without this and 0/199 with it. On a J516C, with the earlier stamp_seed() (see the previous commit), from g15_stamp_base 500000 renders before the wrap with a margin of 100000 and the GPU kept busy (286875 publications behind a flight), the stamps were renumbered at render 400000 and rendering went on past the wrap point to render 526113. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com> (cherry picked from commit 6f7e3df) [ryan: keep reading the margin parameter by value, as on Linux 7.3] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The compute stamp of ordinal n is stamp_seed(COMPUTE_SEED, n): it steps by 0x100 from 0xc1000000 and, after 0x3f0000 computes (4128768: about 390 FLUX.3 1024x1024 images at one node per submission), goes from 0xffffff00 back to 0. Whether the firmware takes that wrap has not been tried either; the TA/FS renumbering of the previous commits does not cover it. Renumber the compute stamp the same way. Add an offset to the compute ordinal used for the stamp and, when g15_compute_reseed_margin is set, at the first publication with nothing in flight inside that margin write the compute stamps back as ComputeGraph::init() leaves them with no stamp base (user COMPUTE_SEED, firmware 0), reset the compute target and move the offset so the next compute counts as ordinal 1. Inside the margin nothing is published behind a flight, as for TA/FS, so the flights drain; the margin is at least one prefix of computes (COMPUTE_SLOTS) and at most half the stamp range. The ordinal itself, which the compute image also carries, keeps counting as the render draw does. g15_compute_stamp_base starts the count near the wrap, to test this in seconds instead of hours. Both parameters default to 0, which keeps the stamp exactly as before. On a J516C, with g15_compute_stamp_base=4023768 (105000 computes before the wrap) and g15_compute_reseed_margin=100000, the stamp was renumbered at compute 5000, the GPU kept running computes up to 159899, past the point where the stamp would have wrapped, and a FLUX.3 1024x1024 image generated fine afterwards. Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com> (cherry picked from commit 736063a) [ryan: read the two compute stamp parameters by value, as the Linux 7.3 module parameter API returns them] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Add a "stamps:" line to asahi-g15/stats with the computes and renders the current numbering has left before the compute and TA stamps wrap, and both renumbering margins (0: off). A script that limits compute work before the wrap can then tell a kernel that renumbers the compute stamp from one that does not, and count from the stamp rather than from boot (g15_compute_stamp_base moves the start). Generated-by: LLM Signed-off-by: Samuel Carreño <soyminero11yt@gmail.com> (cherry picked from commit c3fad65) Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The suite builds admit() from g15/boot.rs against host models. With omacom's T6031 system-sleep hold, admit() reads the ASC control word before it takes the hold, passes whether to hold through system sleep to glue::hold_power(dev, sleep_hold), reads params::sleep_hold() and warns with dev_warn! when g15_sleep_hold=0 on T6031. The model has no dev_warn!, no params module and a one-argument hold_power(), so the admit() control no longer builds. Add dev_warn! (counted), params::sleep_hold() and a failing ASC read to the model, and pick the hold_power() mock from the admit() it is given: with the sleep-hold argument it records the value passed; without it, the model is the old one. Every existing scenario and mutant runs unchanged on both. For an admit() with the sleep-hold argument, also check that the hold is taken through system sleep only on T6031 with g15_sleep_hold on, that g15_sleep_hold=0 on T6031 warns once, that T6030 never holds through sleep, and that a failing ASC read returns before any hold is taken on either SoC. Four mutants (the hold on any platform, ignoring the parameter, no warning, the ASC read after the hold) each fail one of those checks. Signed-off-by: Chris Kearney <303316+chriskearney@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 7621425) [ryan: drop the omacom pull request number; that sleep hold is not in this tree, and the model still builds the admit() without it] Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…alues The parameter buffer series came with four new module parameters: g15_pb_blocks (initial posting, 64), g15_pb_reclaim (2), g15_pb_idle_ms (1000) and g15_pb_reclaim_blocks (1024). The fleet kernel builds the aurora module with G15 off, and the module! parameters are not gated on it, so all four would show up in /sys/module/aurora/parameters on every Mac, and on an M3 they are knobs nobody should need to touch. Make them constants in hw::tuning with the same values: PB_BLOCKS, PB_RECLAIM, PB_IDLE_MS and PB_RECLAIM_BLOCKS. params::pb_blocks(), pb_reclaim(), pb_idle_ns() and pb_reclaim_blocks() now return them, so the PB code is unchanged. The behaviour on an M3 is the series default. g15-pb-growth-tests.py checks that production's four accessors return exactly those constants, and its own accessors start from them, so its cases that vary the values still run. The zero-words harness pins the new hw.rs bytes; the T6030 tables are unchanged. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
… parameters The stamp renumbering series added g15_stamp_reseed_margin and g15_compute_reseed_margin, both 0 (renumbering off) by default, and two testing parameters that start the stamps at a chosen ordinal. Off by default, the M3 GPU still reaches the TA stamp wrap after hours of desktop use, and the wrap through zero has not been tried on hardware. The parameters would also show up on every fleet kernel, G15 or not. Renumber at a fixed margin of 100000 renders and 100000 computes before each wrap, the margin the series was run with on a J516C, as hw::tuning::STAMP_RESEED_MARGIN and COMPUTE_RESEED_MARGIN. Compile-time checks keep them inside the bounds the parameters were clamped to. Drop the two testing parameters: the stamps start from their seeds again, as before the series, and the engine's stamp bases start at 0. The stats line prints the fixed margins. The zero-words harness pins the new hw.rs bytes; the T6030 tables are unchanged. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Binding G15 slots at publication split the shared Uat::bind() into bind_inner(vm, wait), with bind() as its waiting form and the G15-only try_bind() as the other. The M4 MMU retention suite extracted bind() alone and no longer built. Extract bind_inner() with it and give the slot allocator model the non-waiting try_get(). The cases are unchanged: bind() still takes the waiting path, which is the only one the G16 and G17 backends use. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Bring in aurora-wip at e4b030d, which now carries the integration/aurora merge, so this lane is gated against the current tip. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Contributor
Author
|
Folded into the single omacom up-port branch omacom-sync/all (head b463cf8), which carries this lane unchanged as a merge. One PR for the whole up-port follows once the combined kernel has passed the hardware regression run. Per-commit verdicts above stay as the record. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This brings the G15 lane of the omacom
integration/auroraup-port onto aurora-wip: the M3 Pro/Max (T6030/T6031) GPU backend work that our tree lacked, the raw firmware statistics debugfs file for the older GPUs, and the host tests that go with them. Every omacom commit was read and checked against our tree before it was taken.Our G15 backend is omacom's at
omacom caafb8e7a1b2plus our 7.3 and shared-interface adaptations (#602 among them), so most of the lane was missing, not superseded.What it brings
try_module_get()before the firmware starts. A disabled GPU node left by the boot loader is reported./sys/kernel/debug/dri/<N>/asahi_statsis read-only. Only the G13/G14 manager creates it, so of the fleet only the M1 Pro and M2 get it. The ABI doc is included.Uat::try_bind,VmReadGuard::covers_rangeandBoard::DeviceTreeare built only with G15, so the G16 fleet kernel has no dead code.What changed on the way in
g15_pb_blocks,g15_pb_reclaim,g15_pb_idle_msandg15_pb_reclaim_blocks. The stamp series addedg15_stamp_base,g15_stamp_reseed_margin,g15_compute_stamp_baseandg15_compute_reseed_margin. Themodule!parameters are not gated on G15, so all eight would have shown up on every fleet kernel.hw::tuningconstants now, with the series defaults (c0cd9aa5889c).a91ef825ace8).*param.value(). The PB host model returned&u32, so the host test passed while the kernel would not have built. Each commit now reads by value, as 7.3 does.omacom 289bcca8fd86gatedVmReadGuardonCONFIG_DRM_ASAHI_UAT_ADOPTION. We do not have that symbol, andVm::read_user()(G15 or G16) calls it, so the G16 fleet kernel would not have built. It is gated on G15 or G16 instead.drivers/soc/apple/display-gate.candAPPLE_DISPLAY_GATE. It only touches the T6031 arm. The T6030 and T8122 arms, and the T6041 handoff, are untouched.drm_dev_unregister()removes the debugfs file, and waits for its readers, before the registration data that owns the snapshot is dropped.drivers/gpu/drm/asahi/tests/(where nothing ran it) totools/asahi/asahi-stats-raw-tests.pyand is registered (14432bc40991).tools/asahi/run-host-tests.py, not in omacom'stools/aurora-ci.scripts/dtcfor device-tree tests, and CI installsfdtget(bb1b0c80c14f).hw.rsbytes.Uat::bind()intobind_inner()(444919ed4cb7).Per-commit verdicts (all 46 lane commits)
81399ec579e6c9efb090c676,e085a95c50cdea34dfd32a9949ab353e8f3694148052c8423e1ced53ae1a7eae5b05328c3a7dea21d89eb91c280b3294c0cd9aa5889c.f637d677ebb754941febebcfd2ad7137409159aced969cbe330a11a0d922ae93621adf50ddd0598a4f06c562b82dd665aeffd0e53b42, as in omacom.6ce5b84d53deaa142eed3a7c48142e6e63a9a089fd06488a2c428477bc202c916d27ae4ebc4f74455fcd8b0cbd58bf95aaba39eef4ae095edba0d1bd1cf552707286aeffd0e53b42068c2fa3a45a23a7bd131f1ba18d9316c9af79f789160c73bcb02253d4867ccdfe85843dc45c861d1b28bb3ce596fa1ebind()isbind_inner(wait = true), unchanged for the other GPUs. Our 2 M4 checks are kept.2db2e9ffb62f289bcca8fd862a3ddc79d8f29bb74767dcd4APPLE_T6030_GPU_PMP_LINK+ apple,t6030 + t6030-pmp-v2 only. Compiled out in the fleet config.6e5b91ab8ae19d5fd8f2edca0652b14233925af49598aac5e91fc1b5aee98ea9a7235304of_device_table!form. Test registered in run-host-tests.py.6ec4d35fc5c4c69f2b11886550308e74f6c141aa66da56badfc916868c9bca6c77a09ff0ca05e40950596c9836868d26cc35ef24cf7b88e3cc7d7a6135d8cd7020cdf5d723338c5caf28934a8bc6a9fa0bb710fedeb10a56a9c6212c155f323fbd0eec990a229ce2cf328e9a986132e6f580d777cc26a24483ca860b6a26ecc22118cb347beb9f27478f2d2ac34361918150f30fd720c59f572e0aa6ffeecc8cc5fead967fa58fb7553f083f3b251ab55e958737b3a3a1b36eb5541f3e46b352a91ef825ace8.1761ce507dcf6f7e3df42fab433c2871ce31736063aa051269617c1a556cc3fad65647f0d8bd85f040febcedca07964b53bb661265d9a29de9576a9089e658c75ad3,53bb661265d9762142518c419f2b5e61bf0bOur own commits:
bb1b0c80c14f: run-host-tests gives device-tree tests a built dtc.14432bc40991: the stats test moves to tools/asahi.c0cd9aa5889c: the PB values become constants.a91ef825ace8: the stamp margins become constants.444919ed4cb7: the asahi-m4 fixture follows bind_inner.Gates
The branch merges aurora-wip
e4b030d746f2(0c738003d4e8). All results below are for that tree. The last message-only rewrite left the tree unchanged.fleet14on5cf4c5e5: rc 0, 7 warningsBUILD-OK 7.3.0-aurora-omsync-g15, 5872 modules, same 7 warningsCONFIG_DRM_ASAHI_G15=y)e4b030d7t6030-pmp-dt-tests,g15-display-order-testsandasahi-stats-raw-tests.CONFIG_DEBUG_FS=nbuild.Hardware regression plan (for the coordinator; not run here)
The fleet kernel has
CONFIG_DRM_ASAHI_G15off. All of g15/, the T6030 PMP GFX report and the T6030/T6031 DT changes are compiled out or apply only to M3 DTBs. On the fleet, only these shared paths run:bind_inner(wait = true), with the same behaviour. G13 and G14 bind through gpu.rs, G16 through g16/vm.rs.VmReadGuard, with the same exec lock and loop. Only G16 calls it, from the stream gates./sys/kernel/debug/dri/<N>/asahi_stats./sys/module/aurora/parametersmust show no new entries.Each machine: boot the base (aurora-wip
e4b030d7) and the candidate (7.3.0-aurora-omsync-g15). Comparedmesg -p3 | wc -landaurora-diag check --expect, and diffls /sys/module/aurora/parameters. None ofg15_pb_blocks,g15_pb_reclaim,g15_pb_idle_ms,g15_pb_reclaim_blocks,g15_stamp_*org15_compute_*may appear.vkcube --c 600on the offscreen/headless surface, or a shortdeqp-vkslice. Thendmesg | grep -i -E "asahi|aurora|gpu" | grep -i -E "fault|error|timeout"should be empty.sudo cat /sys/kernel/debug/dri/*/asahi_statstwice, 5 s apart, under load.asahi_stats_v1.messages countmust grow.count=0line must carry no payload.asahi_statschecks.modetest -M appleshows the panel, which exercises the apple_drv publish path.vkmarkorglmark2-es2-waylandfor a few minutes. This exercisesUat::bind()andVm::read_user()through the G16 stream gates.asahi_statsfile. Theaurora-g16debugfs is unchanged.asahi_statsfile. Theaurora-g17debugfs is unchanged.Runs only on hardware we do not have. Everything under drivers/gpu/drm/asahi/g15/, the T6030 PMP GFX report (
APPLE_T6030_GPU_PMP_LINK), the t6030.dtsi PMP guard and the T6031 display gate default. These need M3 Pro/Max (T6030/T6031) hardware.What only M3 hardware can prove
Claims in the omacom PRs, recorded but not relied on:
🤖 Generated with Claude Code