[GehrmannSolutions]

Nothing limits the J613's CPU temperature today. With the four P cores busy at 4056 MHz, the die sensors pass 107 °C at full clock and reach 111 °C after two minutes, still rising. T8122 has no fast die-temperature limit (apple,fast-die-effort), and nothing acts on the SMC's thermal pressure. The GPU's thermal limit also finds no SoC die zone on J613, so a performance cap above state 2 runs the fanless GPU with no temperature feedback.

What

• Patch 1 (DT, t8122): per-CPU power for every OPP of both clusters (opp-microwatt). Without it, power_allocator has no power actors ("is not a power actor") and cannot throttle. The values are measured on a J613 through the SMC's cluster power keys (cluster pinned to the state, four CPUs busy minus cluster idle, divided by four) and fitted so that they rise monotonically. Side effect: T8122 gets an energy model for EAS too.
• Patch 2 (DT, t8122): #cooling-cells on the CPU nodes, and six SMC die sensors as the first temperature channels of the SMC hwmon, as on t8140. Te05/Te0P cover the E-cluster groups. Tp05/Tp0L/Tp0b/Tp0r are, for each P core, the key that rose most with only that core busy.
• Patch 3 (DT, j613): one thermal zone per die sensor, each throttling both clusters through power_allocator, as on the fanless J700: switch-on 58 °C, control 95 °C, critical 110 °C, E cluster weighted 3:1 and capped at cooling state 3 (2004 MHz). sustainable-power is 6 W from load tests (below).
• Patch 4 (macsmc-hwmon): a J613 board entry. Die keys: the six Tg keys that rose most with only the GPU busy, plus the CPU die keys of patch 2. Pressure key: mTPL. With it, macsmc_soc_die exists and the GPU's thermal limit gets a reading.

Other boards are unchanged. The DT patches need the new DTBs (boot loader / installer); the hwmon entry only matches apple,j613.

Tested (J613, MacBook Air 13" M3, 16 GB)

Load tests, 10 min each, with patches 1-3 on our daily kernel (2026-10-14):

sustainable-power	P cores busy	result
none (today)	4 × 4056 MHz	107 °C at full clock, 111 °C after 2 min, rising
1.5 W (J700's value)	4	holds 72 °C at 2.1 GHz (too conservative)
6 W (chosen)	4	holds 90-95 °C at 2.6-3.0 GHz
7.5 W	4	oscillates 2.2-3.6 GHz, 98 °C

With 6 W, all 8 cores busy: 92 °C (peak 96 °C), P cluster 2.2-2.4 GHz, E cluster at full clock. P cores + GPU together: peak 97 °C. E cores only: 74 °C. No trip near 110 °C in any run.

In daily use since 2026-10-15 on our daily kernels, and since today on our test kernel (release 20 5d570a78 + #127 + #135 + these patches):

• 6 cpu-*-thermal zones on power_allocator, sustainable_power 6000 from the DT
• cooling devices cpufreq-cpu0 (20 states) and cpufreq-cpu1 (7)
• energy model for both clusters, no "power actor" errors
• zone macsmc_soc_die with 12 of 12 keys; the GPU reads "SoC die temperature … from zones: macsmc_soc_die"

On that kernel the GPU reads it and stays at cap 2 ("SoC die 60.5 C, runtime cap 2 (618 MHz) of 2..=2"). Running above state 2 on this base with asahi.t8122_pstate_cap=3 is my next test. Our earlier kernels did it with an extra GPU patch that is not part of this PR, so I make no performance claim here.

Build: W=1 of t8122-j613.dtb (only the two existing simple_bus_reg warnings for avd/fifo in t8122.dtsi) and of macsmc-hwmon.o (clean). checkpatch is clean apart from the trailers.

Notes

• t8122_start.rs still says "J613/J615 have no SoC die temperature zone yet" and warns about it when pstate_cap is above 2. With patch 4 that is no longer true for J613. I can send a follow-up for the warning if you want it in the same series.
• J615 (15") is not covered; I have no J615 to pick its keys.
• SiliconForest already carries drm/asahi: retain state 2 as the T8122 thermal fallback #135 (thermal fallback at state two), which reads the same zone. Patch 4 gives J613 the zone without a soc_die_keys= override.

(Measurements, patches and this text by TARS, my Claude Code agent, with me running the machine and reviewing; Signed-off-by is mine.)

🤖 Generated with Claude Code

https://claude.ai/code/session_017YMqWu7A3VwEYtHaA1TusK

[GehrmannSolutions]

Follow-up on the cap-3 test: on release 20 + #127 + #135 + this PR, asahi.t8122_pstate_cap=3 on a J613. #135 finds macsmc_soc_die 3 s after start and raises the runtime cap from 2 to 3 (796 MHz) on its own. llama-bench (Vulkan, all layers on the GPU), 10 min: prompt 41.3 t/s and generation 2.17 t/s, versus 32.4 / 1.85 at cap 2. SoC die max 77.7 °C, the cap stayed at 3, no GPU fault. t8122_start.rs still warns at start that J613 has no die zone; I can send the follow-up that drops that warning for boards with a hwmon die entry.

(Test and text by TARS, my Claude Code agent.)

[tonibergholm]

Independent J613 test on the older 14.x firmware profile: the DT changes from head 8fd1bf481afe6fcadaa04001b2bcd435616b705b booted on kernel 7.1.12-2-20261015.19-sep-ARCH (source 5ec1028c81526e1ed31db2b97e47edf8663e83cb).

All six CPU keys are readable floats on this machine. Six 6 W power_allocator zones registered, both cluster energy models were created, and each zone bound to both CPU cooling devices. Conservative manual cooling requests lowered and restored both cluster frequency ceilings.

I also checked the automatic path with temperature emulation, keeping actual TCMz below 73°C:

• At simulated 100°C, the allocator budget fell to 5.0–4.4 W. A short single-thread workload requested about 3.3 W, so no ceiling reduction was needed.
• At simulated 108°C, requested/granted power crossed (for example 3905/3054 mW), and the P-cluster ceiling fell from 4056 to 3636/3288 MHz. Clearing emulation restored 4056 MHz.

These are kernel energy-model estimates and QoS ceilings, not independent electrical-power/effective-frequency measurements. This does not qualify sustained regulation at real high temperatures, sensor accuracy, critical shutdown, or higher GPU states. GPU ceiling stayed at state 2 / 618 MHz.

This was a DT-only one-boot trial: the existing built-in hwmon driver and explicit soc_die_keys override remained, so the new default-key/pressure C change was not tested. The original stage2 boot image was restored and hash-verified after boot; the trial DT remains active in memory for this session.

Selected native evidence, source/build/boot preflight.

Tests and this report were performed/written with Codex; Toni operated the laptop and approved OS authentication.

Sleep follow-up: a 128.66-second lid sleep/resume passed, with suspend success +1 and no failure. All six CPU zones remained readable and bound to both cooling devices through matched pre/resume and30/60/120-second samples. Sensor values continued changing. Sleep evidence. Post-resume actuator retests also passed: P ceiling4056→3960→4056MHz and E2748→2556→2748MHz; both cooling states restored to zero. The original stage2 hash was verified again. Automatic thermal regulation after resume was not retested.

Bounded native-input response on Aurora .20

The retained DT-only trial from this PR head 8fd1bf481afe6fcadaa04001b2bcd435616b705b is also running on 7.1.12-2-20261017.20-sep-ARCH. A bounded test temporarily lowered only the cpu-e1-thermal alert/control trips to 45/50 C. Critical remained 110 C; 6 W sustainable power, PID parameters, all other zones and GPU state-2 cap were unchanged. No emulated temperature was written.

Observed QoS ceilings reached P=2808 MHz and E=2004 MHz (maximum cooling states 11 and 3). These are requested limits, not independently measured frequencies. The independent 75 C guard stopped the worker after 8.099 seconds at a maximum reported zone temperature of 75.890 C; CPU-zone peak was 62.410 C. The target did not settle, so this is not a stable-regulation pass or qualification of the normal 95 C control point.

Original 58/95 C trips and 4056/2748 MHz ceilings were restored, both cooling states returned to zero, and the worker/rollback timer are inactive. Sustained real-temperature regulation, sensor accuracy and critical shutdown remain unqualified. Selected evidence.

TCMz versus the proposed default key list (20 October)

A read-only comparison on J613, .20 / c46d7dcd, older 14.x firmware profile, with the retained DT-only policy and existing explicit soc_die_keys override: over 90 passive samples, TCMz and the active aggregate peaked at 74.718 C, while a userspace maximum of this PR's twelve default keys peaked at 53.213 C. At the TCMz peak, the selected CPU keys were 45.924–53.213 C and selected GPU keys 41.576–43.527 C. Reads are sequential, not atomic. No added workload, external display, active-key change, guard change or clock increase; GPU remains capped at state 2.

This does not establish that TCMz is faulty or validate replacing it. Is its omission from the proposed defaults intentional for a known sensor/aggregation reason, or is the list simply based on the CPU/GPU load-response selection described above? It matters when comparing temperatures between the override and default-key test reports.

Selected paired evidence. Comparison and update performed with Codex on Toni's machine.

Passive numeric sensor readings (21 October)

Same J613 / T8122, .20 / c46d7dcd, explicit TCMz+12 Tg override, GPU capped at state 2. During 61 sequential samples over 60 seconds without a deliberate workload, TCMz and the aggregate peaked at 79.625 C; the highest sampled CPU-zone peak was 65.697 C. Background work was not isolated. Every selected Tg channel had 33 nonpositive samples (zero or -2.849 C); the cause is not established.

The exact release-20 hwmon source preserves the float sign, propagates read errors separately, and accepts -40 to 150 C in the hottest-channel aggregate. These numeric values therefore do not themselves make the aggregate fail. This is not proof of physical accuracy, a bad TCMz sensor, or power-gating behaviour. No keys or guard thresholds were changed. A separate single-E-core build attempt was stopped by the independent 75 C guard after four seconds; it produced no module.

Passive ranges and pinned source audit, guarded-build stop. This supplements the TCMz/default-key question above; it does not qualify higher GPU states or alter the proposed defaults. Observations and source audit performed with Codex on Toni's machine.

[garymeyerca]

Independent full-kernel J613 / 8-core M3 Air boot check with release 20 (c46d7dcdb8712ea9aeb0ce47b439ffae76371e55) + #135 (46b5a0981c4955cf33b7275c4001d820791b9f08) + this PR (8fd1bf481afe6fcadaa04001b2bcd435616b705b). This includes both the DT and hwmon C changes. No macsmc_hwmon.soc_die_keys= override.

Booted 7.1.12-2-20261019.146135-test-ARCH on the older 14.x GPU firmware profile (RTKit-2419.140.12.release), Mesa 26.1.4:

• All 12 default SoC die ... hwmon channels appeared and were readable.
• macsmc_soc_die appeared; the GPU thermal governor explicitly reported receiving its SMC die readings. Initial capture: hottest die 52.010°C, battery 33.200°C, CPU zones 47.503–52.010°C.
• All six CPU thermal zones used power_allocator, each with 6000 mW sustainable power and bindings to both cpufreq-cpu0 and cpufreq-cpu1 cooling devices.
• Hardware OpenGL red/blue readback and Vulkan compute readback passed with the Apple M3 renderer. Three offscreen glmark2 refract/terrain runs completed without an observed GPU fault; sampled die peak in the third run was 53.698°C.
• The production host/runtime test suite also passed 58/58 before boot.

GPU ceiling remained state 2 / 618 MHz throughout this first boot. This confirms the default sensor mapping is exposed and consumed on this machine; it does not yet qualify higher GPU states, automatic CPU cooling under sustained heat, sensor calibration, critical shutdown, or suspend/resume. The firmware's instantaneous MHz field still reports zero, so 618 MHz refers to the configured state ceiling.

Test work and this report performed with Codex; Gary operated the laptop and authorized the test installation and reboot. Higher-clock testing will follow separately.

[garymeyerca]

Further full-kernel J613 / 8-core M3 Air testing on release 20 + #135 + this PR, using the default SMC die-key mapping without soc_die_keys= overrides. Exact build/boot details are in my earlier comment above. The thermal governor receives macsmc_soc_die, and observed firmware peak states reached each tested ceiling (3, 4 and 5). The instantaneous MHz field still reads zero; MHz below denotes the configured table state.

Boot policy retained asahi.m3_boot_pstate=2 asahi.m3_thermal=on asahi.m3_thermal_hot=75, changing only t8122_pstate_cap and m3_max_pstate between trials. All voltage/frequency entries are the existing firmware-derived table values.

Repeated shader workload: identical gpu-heat 20 1920 1080 128 binary/settings, three measurements after a 5-second warm-up at each ceiling, on battery:

Ceiling	Three runs (FPS)	Mean FPS	Sampled die peak during warm-up/measurements
3 / 796 MHz	121.0, 124.3, 122.7	122.67	55.370°C
4 / 928 MHz	136.1, 137.0, 136.8	136.63	54.338°C
5 / 1056 MHz	150.4, 151.3, 151.5	151.07	62.539°C

State 4 averaged 11.4% above state 3. State 5 averaged 10.6% above state 4 and 23.2% above state 3 in this shader workload. These are small, separate-boot synthetic comparisons, not general desktop or performance-per-watt measurements. Earlier 618/796 MHz glmark2 refract/terrain samples overlapped; I do not infer a reliable gain from those.

OpenGL red/blue and Vulkan compute readback passed before and after each state's load test. A further 90-second GPU workload at each ceiling, including the fallback trials below, completed with exit 0 and no observed GPU job fault, timeout or over-cap failure. Physical die-key peaks during those runs were 54.166°C (state 3), 53.213°C (state 4), and 56.807°C (state 5).

Live #135 fallback checks at each of states 3, 4 and 5, while GPU jobs ran:

• Simulated 84°C through macsmc_soc_die/emul_temp: direct fallback to state 2 / 618 MHz, with reason critical.
• Clear emulation: native readings resumed and the governor climbed back to that boot's ceiling, one state at a time.
• Simulated invalid 1°C: direct fallback to state 2, with the out-of-range reading reason.
• Clear emulation: native input and the configured ceiling recovered again.

Emulation was cleared after every trial. The six CPU zones and physical hwmon channels retained native readings throughout. This checks hot/invalid-input response; it does not test sensor disconnection, sensor calibration, real high-temperature regulation, critical shutdown or suspend/resume. The stock kernel remains the default boot choice; higher-state tests use separate retained entries.

Tests/report performed with Codex; Gary operated the laptop and authorized authentication and reboots.

Installation/ceiling follow-up: a subsequent attempt with t8122_pstate_cap=6 was refused before GPU startup: t8122_knobs.rs in this build accepts only states 1–5. I missed that guard when preparing the entry. This is not a 1170 MHz stability test or evidence of a #146 thermal regression; no state-6 GPU workload ran.

The failed boot also had missing Wi-Fi/zram and other kernel modules. The stock boot at 20:48 local ran linux-modules-cleanup.service, which removed the manually installed test kernel's module directory because pacman did not own it. This explains the missing-module failures and the 90-second zram device wait on the subsequent test boot. The experimental install needed proper package registration; that omission was mine. I have restored the original stage-2 image and pre-test boot menu. The current stock kernel has working Wi-Fi and passes hardware OpenGL/Vulkan readback. Earlier state-3/4/5 measurements remain bounded test results, not a qualified daily-use setup. Further testing requires fixing packaging and reviewing the explicit state-5 guard first.

Packaged state-6 retest (subsequent to the failed attempt above): the install now uses a separate, pacman-owned linux-aurora-j613-cap6 package, with kernel 7.1.12-2-20261019.146135cap6-test-ARCH. Wi-Fi, zram and module loading pass on both its 1056 and 1170 MHz boots; the earlier missing-module/90-second-wait problem did not recur. Stock remains the default boot choice.

This retest adds a local experimental guard patch beyond #135 and #146. Base c46d7dcdb8712ea9aeb0ce47b439ffae76371e55, #135 head 46b5a0981c4955cf33b7275c4001d820791b9f08, #146 head 8fd1bf481afe6fcadaa04001b2bcd435616b705b. The extra patch extends admission from state 5 to state 6 only with active m3_thermal=on, rejects state 6 with Off/Hold, and leaves state-2 critical/missing/invalid/stale fallbacks intact. It uses the existing firmware-derived voltage/frequency entry, without voltage edits. Local and remote host tests: 61/61; full ARM64 build and package audit passed, including matching architecture/vermagic on all 1,878 modules. Local patch SHA256: 6b407b5bee673a6ee938b456cb59650d8006f75e56268e5211857d3234a39f77.

Same packaged kernel, GPU workload binary and settings as above, on battery, separate boots, no Chromium processes running during either isolated comparison:

Configured ceiling	Three runs (FPS)	Mean FPS	Sampled die peak
5 / 1056 MHz	151.6, 151.0, 151.4	151.33	57.291°C
6 / 1170 MHz	165.9, 165.7, 165.6	165.73	56.807°C

State 6 averaged 9.5% higher in this shader workload. Firmware peak-state telemetry reached 6; instantaneous MHz still reads zero, so this is a table-state result rather than a continuous frequency measurement. Earlier background-contended state-5 samples (138.7, 109.3, 110.2 FPS) were excluded from this isolated comparison. Small separate-boot samples do not establish general desktop performance, thermal efficiency or performance per watt.

A further 90-second state-6 load, including the fallback trials, exited 0; all twelve physical SoC die channels remained native, with sampled peak 58.245°C. Kernel logs show direct 6 -> 2 (618 MHz) for simulated 84°C (critical) and invalid 1°C (out-of-range), followed after each clear by 2 -> 3 -> 4 -> 5 -> 6. Emulation was cleared. Post-load OpenGL/Vulkan readback, Wi-Fi, zram, module ownership and module-load service checks passed, with no GPU job fault, timeout or over-cap failure observed. The early start code still prints a stale unconditional “no SoC die temperature zone” warning for caps above 2; the later runtime governor binds the actual die zone, and the live fallback/recovery results above verify that feedback is active.

These remain bounded tests with simulated sensor input. Real hot regulation, sensor calibration/disconnection, critical shutdown, suspend/resume and daily-use stability remain unqualified. Tests/report performed with Codex; Gary operated the machine and authorized the work.

Extended state-6 follow-up, same packaged kernel and local admission patch described above:

• 900-second continuous GPU load: gpu-heat 900 1920 1080 128 completed with exit 0, 149,960 frames, 166.6 FPS. All twelve native physical die channels were sampled every ~2 seconds (446 samples), peak 67.995°C. Approximate first/last one-minute intervals were 165.6/167.3 FPS, with no performance fade observed. The runtime ceiling stayed at 6, firmware peak-state telemetry reached 6, and no GPU job fault, timeout, over-cap failure or thermal cap reduction appeared. Post-load OpenGL/Vulkan readback, Wi-Fi, zram, package ownership and module loading passed. This remained below the 75°C reduction threshold, so it does not qualify real hot-temperature regulation.
• Isolated, visible Chromium check (~64 seconds): WebGL2 used ANGLE/Zink on Apple M3; 3,862 animation frames, 32 correct red-pixel readbacks, zero context loss or script/GL errors. CSS animation and local 1280×720/30 H.264 looping playback were also exercised, with changing decoded-frame hashes and a screenshot reviewed. Chromium reported 1,920 video frames, 8 dropped and zero corrupted; 1,935 video-frame callbacks were observed across loops. GPU compositing/WebGL were enabled, but video decode was disabled_software: this establishes software-decoded playback with GPU rendering, not hardware video decode support or arbitrary website compatibility. The test used a separate browser profile/window.
• One actual s2idle suspend/resume cycle: kernel entry/exit recorded with unchanged boot ID; suspend statistics show success=1, fail=0 and no failed device/step. Graphics readback, Wi-Fi connectivity, zram and die/CPU thermal zones recovered. A further 90-second GPU load completed at 167.0 FPS, physical die peak 63.479°C, followed by passing OpenGL/Vulkan and system checks with no GPU faults observed. Wi-Fi logged transient brcmfmac association/join-pref -52 messages during resume but recovered to full connectivity. Wake IRQ was 106 (apple-dockchannel-rx). This was a single short cycle, without qualifying repeated resume, long sleep, wake-source behavior or sleep battery drain.

The experimental state-6 kernel remains running, with stock retained as the next-boot default. These additional checks improve the evidence for this exact setup; they do not establish general daily-use stability. Real hot regulation, sensor calibration/disconnection, critical shutdown, repeated/long suspend and broader application coverage remain outstanding. No state-7 entry has been enabled.

State-7 bounded follow-up on the same J613 / 8-core M3 Air: a separate pacman-owned linux-aurora-j613-cap7 package boots kernel 7.1.12-2-20261019.146135cap7-test-ARCH. This adds a further local admission extension beyond #135/#146 and the state-6 experiment above: states 6–7 require the active thermal governor; Off/Hold admission for them is rejected, default/fallback remains state 2 and state 8 is still refused. Firmware-derived voltage/frequency entries and the production governor are unchanged. Native state 7 is primary 1278 MHz / secondary 1152 MHz at 910 mV core/SRAM. Full local patch SHA256: ade3f962fe831f2510c8dd5509ba21d7967eba2517e9edeb5ed2f34a1eb625b0. Local/remote host tests: 61/61, now exercising critical/missing/invalid/stale/stuck fallback and recovery at both 6 and 7. Full ARM64 build, package audit and all 1,878 module architecture/version checks passed; kernel .config is unchanged from the state-6 build.

Same shader binary/settings, 5-second warm-up followed by three 20-second runs, on battery with no Chromium processes running:

Ceiling	Three runs (FPS)	Mean FPS	Sampled die peak
6 / 1170 MHz, prior cap6 image	165.9, 165.7, 165.6	165.73	56.807°C
7 / 1278 MHz, cap7 image	177.2, 179.8, 179.3	178.77	56.726°C

That is 7.9% higher in this shader workload. This comparison spans separate boots and different kernel images (the reviewed state-7 admission delta, identical kernel config), so it remains a small synthetic comparison rather than a same-image controlled result or a general desktop/per-watt claim. Firmware peak-state telemetry reached 7; instantaneous MHz remains unavailable/zero, so MHz denotes the configured firmware table entry.

A further 90-second load, including live fallback checks, exited 0; sampled native physical die peak was 58.927°C. Logs confirm direct 7 -> 2 (618 MHz) on simulated 84°C (critical) and invalid 1°C (out of range). After each clear, native input recovered and the governor climbed 2 -> 3 -> 4 -> 5 -> 6 -> 7. Emulation was cleared; all twelve physical hwmon die channels and CPU thermal zones retained native input. Post-load hardware OpenGL/Vulkan readback, Wi-Fi connectivity, zram, package ownership and module loading passed, with no observed GPU job fault, timeout or over-cap failure. Stock is again the next-boot default; the experimental state-7 kernel is currently running.

State 7 has not yet received the 15-minute load/browser/suspend qualification described above for state 6. Sustained heat, state-7 suspend/resume, real hot regulation, sensor disconnection/calibration, critical shutdown and daily-use stability remain unqualified. No state-8 test entry is enabled. Tests/report performed with Codex; Gary operated the laptop and authorized the work.

State-8 bounded follow-up (2026-10-20), same J613 / 8-core M3 Air: kernel 7.1.12-2-20261019.146135cap8-test-ARCH, pacman-owned linux-aurora-j613-cap8. This is another local admission extension beyond #135/#146, allowing states 6–8 only with active thermal feedback; default/fallback remains state 2, Off/Hold admission above 5 is rejected, and states 9+ are rejected. The production governor and firmware voltage/frequency entries remain unchanged. Full local patch SHA256: d98570a8213d18d3960427f5f910a522546c4bbe887b1fd9448026891c3706ce. Local/remote host tests 61/61; ARM64 build, package ownership, all 1,878 module architecture/version checks passed, with unchanged kernel configuration from cap7.

The highest operating point in this machine's raw Apple ADT PMGR voltage tables is 1338 MHz / 935 mV (secondary frequency 1204 MHz). Those raw entries match the live GPU OPP data. This is model-specific firmware evidence, not a direct macOS frequency measurement. Firmware peak-state telemetry reached 8; instantaneous MHz telemetry is unavailable/zero, so MHz here names the configured table entry.

Same shader binary/settings, on battery, no Chromium processes running: 5-second warm-up then three 20-second runs gave 187.3, 187.1, 189.8 FPS, mean 188.07 FPS, sampled aggregate die peak 55.934°C. This is 5.2% above the prior state-7 mean of 178.77 FPS. Separate boots and different kernel images, same kernel config/workload: a small synthetic comparison, not a general desktop or per-watt claim.

A complete 90-second GPU load with 52 sampled seconds of live fallback testing exited 0. Simulated 84°C and invalid 1°C each caused direct 8 -> 2 (618 MHz); clearing each restored native input and recovery through 3 -> 4 -> 5 -> 6 -> 7 -> 8. Emulation was cleared. Earlier runner attempts were incomplete because authentication delayed the workload or the privileged-to-user launch lost the experimental Mesa environment; those are retained separately and are not counted as successful trials. The final runner explicitly supplies the verified Mesa/experimental opt-in environment and starts its workload after authentication.

Near the end of the successful final load, native physical SoC die Tp0b reached 81.224°C, after emulation had been cleared. The governor stepped down 8 -> 7 -> 6 -> 5 -> 4 at native 81.2/78.2°C. A localsearch-3 indexing process was observed using 91.8% CPU afterward; its contribution was not isolated. This demonstrates observed native hot regulation, and means the final load should not be described as sustained operation at 1338 MHz. Earlier standalone 90/120-second loads passed with physical peaks 57.322/60.543°C.

Post-load OpenGL/Vulkan hardware checks, Wi-Fi connectivity, zram, package ownership and module loading passed; no GPU faults/timeouts were observed. The experimental cap8 kernel is running; stock is the next-boot default. State-8 15-minute load, browser/video, suspend/resume, sensor calibration/disconnection and daily-use qualification remain outstanding. This update supersedes the earlier “no state-8 entry” status. Tests/report performed with Codex; Gary operated the laptop and authorized the work.

Follow-up: higher GPU states 6–8 now have a dedicated tracking issue, #164, including the exact local patch, tested results and remaining qualification. This comment retains the historical evidence; future higher-state updates will continue there. Sensor/CPU thermal-zone validation remains on #146.

[GehrmannSolutions]

Thank you @tonibergholm and @garymeyerca for the independent J613 tests. Between them they cover the DT-only path on the older 14.x firmware profile (including lid sleep and a bounded native low-trip run) and the full kernel with the default die-key mapping and no soc_die_keys= override. Gary's state-8 run is also the first native, not emulated, step-down I have seen on this board: Tp0b at 81.2 °C took the GPU from 8 to 4 on its own.

On the stale "no SoC die temperature zone" warning that Gary also saw for caps above 2: I offered a follow-up for it above, but none is needed on the current base. On integration/aurora at 1b4997bbab62 (Asahi 7.2.10), t8122_start.rs is gone and that warning no longer exists. The runtime limit there requires the SMC die zone on J613/J615 (required_zones() in m3/m3_thermal_policy.rs), which is the macsmc_soc_die zone that the J613 die-key entry in this PR provides.

This PR still merges cleanly onto that base (checked locally with git merge-tree). Higher GPU states stay out of scope here; Gary's local admission patches for states 6–8 would be a separate change.

(Checked and written by TARS, my Claude Code agent.)

[chriskearney]

Reviewed exact head 8fd1bf481afe6fcadaa04001b2bcd435616b705b: all three changed files, the current thermal/hwmon/cpufreq consumers, and the effective merge onto 0571e8d7. Source review supports an integration merge subject to required CI and the full merge queue.

DT controls built all seven affected T8122 boards plus a J700 control against the current tree and merge result; existing dtc warnings were unchanged apart from line numbers, and J700 was byte-identical. Sensor indices remain stable when a key is missing; the cooling maps and default power_allocator path resolve as intended. Shared cooling devices select the most restrictive zone target rather than adding targets.

This changes runtime policy: J613/J613-25g83 gain six CPU zones and a 110 C critical trip; all T8122 boards gain the energy model/EAS and hwmon channel declarations. Under heavy load, the allocator can reduce clocks below the 95 C control point. Existing public J613 evidence is on 7.1.12 and the older firmware profile; it is not a merged-7.2 or 25G83 qualification.

The unanswered TCMz/default-key discrepancy and the existence/meaning of these keys on 25G83 remain explicit hardware/release limitations. Byte-identical hwmon code establishes the read path, not firmware sensor semantics or calibration. No physical boot, sensor-accuracy or critical-shutdown pass is claimed by this review. Higher GPU-state admission remains out of scope.