Repository navigation
drm/asahi: add the T6041 25G83 profile captured on the J616C (stacked on #525) - #916
Closed
AxxzyWasTaken wants to merge 18 commits into
Closed
AxxzyWasTaken wants to merge 18 commits into
AxxzyWasTaken wants to merge 18 commits into
Conversation
Reuse the existing SoC and PMGR descriptions as the shared T604x base. The J616s compiled tree keeps every node and property unchanged. Assisted-by: LLM
Describe the Max CPU, OPP and register-window differences on the shared base. Preserve the qualified J616c node and property values. Assisted-by: LLM Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Move identical register-window constructors into a family helper. The T6040 and T6041 initialization-data checks retain their exact values. Assisted-by: LLM
Select a static 25F84 profile and admit the normalized loaded image measured in three qualification boots. Remove exploratory overrides and unknown-image admission from the support path. Assisted-by: LLM Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Keep the reason-0 and cancellation handling scoped to 25F84, with serial rendering explicitly opt-in. Concurrent-render firmware restarts and complete recovery remain unresolved. Assisted-by: LLM
Add gated 26.5.2 firmware acceptance and headerless powerlog parsing for the T6041 display controller. Assisted-by: LLM
Wait for the flip notification before completing commit cleanup so framebuffer ownership follows scanout completion. Assisted-by: LLM
Give bootarg access width its own hardware setting and patch through one aligned buffer. Preserve surrounding bytes and verify changed words. Synthetic MMIO checks cover malformed tables, bounds and failed readback. Assisted-by: LLM
Describe the six amplifiers and headphone jack in the J616c board DT. Stop playback when the protection lease is lost. Assisted-by: LLM
Limit admission to the qualified J616c machine and firmware layout. Apply the capability per device without allocating or changing the shared variant descriptor. Assisted-by: LLM
Register the watchdog against its platform device and apply the configured nowayout policy. Assisted-by: LLM
Build the production initialization objects with their soft-float types and compare constants with explicit capture inputs. Keep T6040 per-chip calibration validation separate; include no captures or local defaults. Assisted-by: LLM
m1n1 compares DT CPUs with its physical MPIDR enumeration. Appending the Max cores to the Pro topology put CPU 9 out of order and stopped boot before kernel entry. Define the full family topology in hardware order and remove the extra cores from J616s. Check the compiled DTB order for both SoCs. Assisted-by: LLM
Keep all shared firmware profiles at TA 0x1c890 = 0 and enable mode 1 only in T6041's admitted 25F84 build. Pass that device/build policy through RenderArgs without changing register ordering, merge-buffer writes, fragment programs or serial-render admission. Add KUnit coverage for the policy boundary and constructor output, including SCS array shape and unchanged fragment/G17P arrays. Motivated by AxxzyWasTaken's separate J616C/25G83 implementation results: aurora-silicon#525 (comment) Those results do not validate this branch or its 25F84 firmware; the cluster merge-buffer explanation remains a hypothesis. Validation: patch application/reversal, whitespace and source-scope checks. Not yet compiled, KUnit-executed or hardware-tested. Keep the existing asahi.t6041_serial_render=1 workaround pending the concurrent-render test matrix documented in the PR.
The 32-core M4 Max in the J616C boots through a macOS 26.6.2 stub (iBoot mBoot-18000.161.10), which loads a T6041 image of the 25G83 GPU firmware the M4 Pro runs. Its loaded TEXT (0x60000 bytes, GKTS and ECAP records at 0x59839 and 0x5991c, DATA 0x138000) normalizes to sha256 aa113ed62079bcfdeef0f86c2a8d7eae9f907b03be28ccf298c943951d0effc5. T6041 admits only its 25F84 image, on 40 cores, so this unit's GPU is refused. Admit that image as a second T6041 build. A firmware build can now name the SoC configuration it was measured with; once the build is identified, that configuration replaces the probed one. The 25F84 build names none and keeps its static profile; T6040 and T8140 only gain the empty fields. Built on the host from the driver sources, the T6041 25F84 hardware data, power configuration and region C, and the T6040 builder output, are byte-identical before and after this change. The 25G83 configuration (hw/t6041_25g83.rs) is the one the J616C has run with on this firmware: - 4 clusters with 32 enabled cores (core mask 0xf6_fdbf6fdb), which the probe requires. - Operand-state banks for all 40 core slots (0x80000 bytes), as for 25F84; the enabled slots run to 39. With banks for the 32 enabled cores only (0x68000 bytes, followed by the queue context), a compute load beside rendering hit reason-0 recoveries in 5 of 5 runs, and in 0 of 4 with 40 banks. - Four-cluster deflake and TA mode 1, as for 25F84. Clustered tiling hangs this GPU until the cluster buffers are sized for four clusters. - A compute pool of 96 blocks, which the J616C has run with since 23 Oct 2026; 21 blocks hang its firmware on grids of more than ten workgroups. - The captured register map: six memory controller instances in slot 3 (apple,sgx-active-mcc-bit-vector 0x3f, 32 MiB apart), which moves every window after it 0x30000 further than on the M4 Pro, and no reserved slots. Its hardware data, power configuration, region C and AON table are applied, not built: the contents built on this unit and captured from it on 25 Oct 2026 (hw/t6041_captured.rs), with only the runtime words written over them (completion-ring descriptors and QoS pointer; configuration-status pointer, AON pointer and random word). They equal what the 25G83 builders write for the M4 Pro except for the chip ID, the core count, the register map, four GPU cluster temperature sources, a second sensor-mask word, and the values below. Some captured values exist only because the device tree the J616C boots with has no GPU operating-point, CS or AFR tables and none of the calibration properties the T6040 builder reads (apple,perf-map-a/b, apple,perf-relative-a/b, apple,max-power-mw, the leakage coefficients): this unit's binned operating points in the performance, CS and AFR tables, its 110586 mW power limit and the coefficient derived from it, and the four clusters' leakage coefficients. With those tables in its device tree, the builders could produce them instead. The GPU is not started if the captured contents do not fit: it must have the captured 32 cores, the captured chip ID and register map must equal the configuration's (with no reserved slots), and the FNV-1a 64 hashes of the hardware data and power configuration without their runtime words, and of region C, must equal the capture's. On the host, the written contents hash to those values, and the checks refuse another chip ID, the 25F84 and T6040 register windows, a missing or duplicated window and reserved slots. Not run on hardware: the J616C has run these contents on this firmware only with the 7.2 port of the G17 driver.
Bring the branch up to the current base. The conflicts are in the aurora-silicon#525 commits underneath, so they take the resolutions from aurora-silicon#525 at 3d0938d: the tree is aurora-silicon#525 at that commit, the 25G83 profile and this base.
firmware_variant() now also returns the SoC configuration a build was measured with, so the selection test no longer compiled. Give its model of Build the field, and check that the configuration follows the identified image, and that a build without one and a fixed variant keep the probed configuration.
t6040.dtsi keeps aurora-silicon#525's split. The base dropped dma-noncoherent from a node that moved to t604x.dtsi, so that removal goes there.
Contributor
|
Merge train (MTL, 06/11): can't take this one. None of its 16 non-merge commits carry a |
Contributor
Author
|
Replaced by #1050: rebased onto |
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.
Stacked on #525, so #525 should go in first. Two commits are new:
drm/asahi: add the T6041 25G83 profile captured on the J616Candtools/asahi: model the configuration of a firmware build. The commits under them are #525 as ofc048e0eb6bc8. The merge commit brings the branch up tointegration/aurorawith the conflict resolutions from #525 at3d0938d8da13, so the tree is #525 at that commit, plus these two commits, plus the base.#525 admits the M4 Max only with its 25F84 GPU firmware, on 40 cores. A 32-core J616C booting through a macOS 26.6.2 stub loads a T6041 image of 25G83, which #525 refuses. This admits that image as a second T6041 build:
hw/t6041_25g83.rs) is the one this J616C runs with:hw/t6041_captured.rs), with only the runtime words written over them. The GPU isn't started unless the chip ID, core count, register map and content hashes match the capture.The commit message has the details and the reasons for each value.
Testing
g17-firmware-selection-testsnow also checks that a build's configuration follows the identified image.aop-bootargs-testsandt604x-cpu-order-testspass.run-host-tests.pyrefuses to start on this tree, because three tests from Bring up T6041/J616c GPU, protected audio and HEVC #525 aren't registered with it (aop-bootargs,g17-t6041-initdata,t604x-cpu-order). I ran the G17 set from a temporary copy that lists them.g17-t6041-initdata-tests, which needs native 25F84 captures.aurora-wip,vkmarkon Wayland kept the fragment engine busy (checked infdinfo), and Sober (x86, through FEX) reached Roblox's home screen, with no recoveries in about 2.5 minutes. No game has been played on it yet. That build had two local changes that aren't in this PR: a 96-block render pool, and the larger clustering metadata sizes described below. I didn't try it without them.On current integration/aurora: with the base merged in, T6041 25G83 also picks up upstream's 25G83 partial renders, ray traversal, segment limits and its 44-block render pool. On 7.2 this unit needed 96 render blocks (22 hung it). On 7.2 it also needed bigger clustering metadata with four clusters, or clustered tiling outgrew it on heavy geometry and the firmware killed the render as no-progress (reason 0). This PR has neither change yet. In the 7.3 boot, metadata 3 and 4 were 0x2800 and the larger of 0x800 and the partial-render size, and metadata 1 was 0x44 per block of tiles.
Needs
t6041-j616c.dtskeeps&gpudisabled. For the J616C tree in arm64: dts: apple: Add the MacBook Pro 16-inch M4 Max (J616C) #914, arm64: dts: apple: t6041-j616c: describe the GPU (stacked on #914) #917 does it: theapple,agx-t6041compatible and four-cell operating points.Follow-up: the captured contents include this unit's binned operating points, power limit and leakage coefficients. That's only because the device tree it booted with had no GPU tables. With the loader filling the tables, the builders could produce those values instead of the capture.