Skip to content

pmdomain/soc: apple: T6050 DRAM and fabric floors (PMC voters, CLPC, GPU link) - #1324

Merged
DjDeveloperr merged 3 commits into
integration/aurorafrom
djdev/t6050-memory-floors
Nov 9, 2026
Merged

DjDeveloperr merged 3 commits into
integration/aurorafrom
djdev/t6050-memory-floors

Conversation

@DjDeveloperr

Copy link
Copy Markdown
Contributor

Summary

On T6050 the boot loader leaves every PMC rail with no voter agent enabled, so nothing raises the DRAM controller (DCS) or the SoC fabric above state 0 under any load. On the M5 Pro (J714s) a CPU memcpy caps at about 42 GB/s, DRAM latency is 310 ns, and GPU bandwidth-bound work runs 9.5× slower than on macOS 27.2.

  • pmc: apple,t6050-pmc: five agents (PMP, CLPC, GFX, AP, PMP1; ADT voter-agent), four rails (DCS, SOC, DISP, DISP2; voter-rail-data), DCS states 0-6 and fabric 0-3 (the PMP's dvfs-domain), the pending word after each floor word, agents enabled on DCS and SOC only. The layout follows Jeff Queisser's J775D series (pmdomain/soc: apple: hold the T6050 memory and fabric floor while the GPU has work #886).
  • clpc: apple,t6050-clpc: CPU map DCS {2, 4, 6, 6} / fabric {1, 2, 3, 3} by frequency quartile after three busy samples, and the GPU input (work in flight gets DCS 6 / fabric 3). Idle releases the floor.
  • dts: the T6050 GPU node names the CLPC (apple,clpc).

The binding already lists both compatibles, and the T6050 DT already has the PMC node with CLPC and AP as static voters.

Measurements (J714s, M5 Pro, RAM-boot kit: PR #1012 kit kernel + this series + the T6050 cpufreq profile, GPU calibration words published)

Floor sweep through the AP agent, CPUs at iBoot's clocks (12-thread memcpy, 256 MiB pointer chase):

floor DCS 0 DCS 1 DCS 2 DCS 3 DCS 4 DCS 5 DCS 6 DCS 6 + fabric 2
memcpy 46 GB/s 81 108 149 159 167 171 177
latency 324 ns 246 227 152 148 145 143 135

gpubench (median µs per submission; macOS 27.2 record of the same machine):

test before this series + cpufreq macOS ratio
compute.heavy bw d8 3,165 (42 GB/s) 486 486 (276 GB/s) 332 9.52 → 1.46
copy.bw buf2buf d4 3,165 486 486 453 6.99 → 1.07
compute.light d4 124 54 38 19.8 6.28 → 1.90
compute.heavy alu d8 270 267 267 261 1.02
render.heavy fill 1080p d8 128 126 126 122 1.03

CPU with cpufreq: 12-thread memcpy 252 GB/s, DRAM latency 109 ns (42 GB/s and 310 ns before). The CLPC's status shows reason cpu for a busy cluster at its top state, reason host_gpu with GPU work in flight, and floor 0 at idle; 0 update errors over ~65k samples. Holding DCS 6 / fabric 3 at idle would cost 1.4 W of total system power.

Logs: the run is pm3 in our M5 load-management notes (results, console, DT and kernel hashes).

What else sees it

Only apple,t6050-pmc and apple,t6050-clpc select the new entries; T8132, T8140, T8142, T8152 and T6040 keep their tables. A T6050 GPU node without apple,clpc gets no supplier, as before.

🤖 Generated with Claude Code

The boot loader leaves every PMC rail of the T6050 with no voter agent
enabled, so nothing raises the DRAM controller (DCS) or the SoC fabric
above state 0. On the M5 Pro a CPU memcpy then caps at about 42 GB/s
for 1 to 12 threads and dependent DRAM loads take 310 ns.

T6050 uses the T8140 voter layout with five agents (PMP, CLPC, GFX, AP
and the second die's PMP1, from the ADT's voter-agent) and the pending
word after each floor word that T8132 has. Its rails are DCS, SOC, DISP
and DISP2 (voter-rail-data); the PMP's dvfs-domain lists DCS states 0-6
and fabric states 0-3. As on T6040, agents are enabled on DCS and SOC
only.

Tested on J714s: the PMC enables the CLPC and AP agents on DCS and SOC
(enable words 0xa). With the AP's floor swept by hand, 12-thread memcpy
reads 46, 81, 108, 149, 159, 167 and 171 GB/s at DCS 0-6, and 177 GB/s
at DCS 6 with fabric 2 or 3; DRAM latency falls from 324 to 135 ns.

The layout follows Jeff Queisser's J775D (M5 Ultra) series.

Signed-off-by: Diljit Singh <hey@djdev.me>
The GPU driver reports its work in flight to the CLPC named by
apple,clpc, which then holds the DRAM controller and fabric floors up
while there is some. Without the link, GPU work gets no floor and
bandwidth-bound work runs at about a tenth of macOS's rate.

Signed-off-by: Diljit Singh <hey@djdev.me>
T6050 has DCS states 0-6 on rail 0 and fabric states 0-3 on rail 1. As
on T6040, a cluster requests a state after three busy samples in a row
(12 ms), and the GPU driver reports its work in flight, which gets the
top of the map while there is some. Idle releases the floor.

Tested on J714s (M5 Pro), with the T6050 cpufreq profile loaded:
- CPU: a busy cluster at its top state holds DCS 6 / fabric 3; idle
  clusters at 300 MHz hold nothing. 12-thread memcpy reads 252 GB/s and
  DRAM latency is 109 ns, against 42 GB/s and 310 ns with neither the
  floor nor cpufreq (177 GB/s and 135 ns with the floor alone).
- GPU (gpubench against macOS 27.2): bandwidth-bound compute 3165 ->
  486 us per submission (9.5x -> 1.46x macOS, 42 -> 276 GB/s), buffer
  copies 3165 -> 486 us (7.0x -> 1.07x), light compute 124 -> 54 us
  (38 us with cpufreq); ALU and fill stay at macOS's rate.
- Holding DCS 6 / fabric 3 at idle costs 1.4 W of system power, which
  the release avoids.

Signed-off-by: Diljit Singh <hey@djdev.me>
@DjDeveloperr

Copy link
Copy Markdown
Contributor Author

Retested before merging on the M5 Pro (J714sAP, bare metal, SSD boot), kernel 7.3.0-m5-merge: the M5's integration kernel with this round's rebased heads in place of the old ones (every PR's own patch identical to what is merged; logs in work/m5-pr-merge-20261109). CI green.

Before merging, this round (these 14 PRs, #1323 and the rebased #1254/#1306/#938/#1316/#1199) was test-merged in order onto integration/aurora f9cf6f9 with no conflicts: apple-dt-check.sh 414 → 414 warning lines (0 new) over 137 DTBs, all 20 changed bindings pass, and a local host-test run fails only where integration itself fails with this host's newer toolchain. A full arm64 build of the same set on 8d98b7a was clean.

  • PMC voters and the CLPC bind; under a busy-loop the M clusters go 300 → 2964 MHz and the P cluster to 4608 MHz, with no DVFS error; idle total system power 6.5 W shortly after boot.

🤖 Generated with Claude Code

@DjDeveloperr
DjDeveloperr merged commit 3e2e5ba into integration/aurora Nov 9, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant