Skip to content

drm/asahi: retain state 2 as the T8122 thermal fallback - #135

Open
garymeyerca wants to merge 1 commit into
omacom:integration/aurorafrom
garymeyerca:garymeyerca/t8122-thermal-fallback
Open

garymeyerca wants to merge 1 commit into
omacom:integration/aurorafrom
garymeyerca:garymeyerca/t8122-thermal-fallback

Conversation

@garymeyerca

@garymeyerca garymeyerca commented Oct 16, 2026 •

Copy link
Copy Markdown

With thermal control enabled, raising asahi.t8122_pstate_cap from 2 to 3 also raises the current thermal fallback to 3: max.min(ADT_MAX_PSTATE_LIMIT) uses a generic limit of 5. The governor then cannot return to the default state 2 when the sensor fails, becomes stale or stuck, or the temperature rises.

Keep the T8122 thermal On/Hold fallback at the lesser of its selected ceiling and its default state 2. Preserve the existing fallback for other SoCs, lower ceilings and explicit thermal Off. Keep the latest M3 Max thermal-zone requirements intact and update the runtime documentation to describe the T8122 behavior.

Base: integration/aurora ccd21b7.

Validation:

  • Rust 1.93.1, --edition=2021 -D warnings: 58/58 host tests pass, including the current M3 Max zone tests.
  • Four regression tests cover T8122 ceiling/fallback separation, hot and critical temperatures, absent/failed/stale/stuck readings and hold mode.
  • Negative control: restoring the old fallback calculation makes all four new tests fail while the existing 54 tests pass.
  • Strict checkpatch with --no-signoff and git diff --check pass.

Full integration build and hardware validation (2026-10-16):

  • Apple J613/T8122, eight active GPU cores, OS firmware 14.7, system firmware 27.0, GPU firmware 14.8.3.
  • Built and booted kernel 7.1.12-2-20261016.135-validate-ARCH from combined validation commit 3f707474edf90df80a9fd14c3b47b9459706cc0a, containing this patch and media: apple: isp: restore J613 camera capture on 14.7 firmware #134 on the base above.
  • Full make ARCH=arm64 LLVM=1 -j4 W=1 all passed with Clang/LLD 23.1.1, Rust 1.93.1 and bindgen 0.73.2. Build warnings are retained locally; this is not a warning-free build. The release config retains Rust/Asahi and ISP support, uses a unique local version and Zstd-compressed debug sections, and includes the base's J613 display-gate default.
  • Bounded test boot: asahi.t8122_pstate_cap=3 asahi.m3_boot_pstate=2 asahi.m3_thermal=on asahi.m3_thermal_hot=75, with the existing override exposing 80 candidate Te/Tg/Tp channels through macsmc_soc_die.
  • Raised the thermal-zone reading to 90 C using emul_temp, then cleared it; the runtime cap fell from 3 to 2 and subsequently returned to 3 with real readings. A 35-second compute run returned 21,269 correct results; the firmware summary confirmed peak state 3.
  • Raised the reading to 90 C again and ran compute for 65 seconds: 36,355 results, zero wrong results. The runtime cap dropped from state 3 / 796 MHz to state 2 / 618 MHz. After the transition interval, a firmware summary confirmed peak state 2. The unchanged-reading guard also retained fallback 2 after 60 seconds.
  • GPU progress remained healthy=1; no new GPU timeout/fault/recovery messages were detected during these checks. Thermal emulation was cleared in the cleanup path.
  • Independently sampled raw candidate temperatures stayed between 39.157 and 74.218 C during the thermal test. The initial automatic basic run during startup stopped at its unchanged 80 C guard when one candidate reached 85.203 C; the complete basic run passed after cooling, peaking at 62.656 C.
  • OpenGL/Vulkan readbacks, three short compute checks, three rendering runs and the repeated camera streams also passed on the same boot.

This verifies the bounded cap transition and firmware response on one J613. It does not qualify sensor calibration, complete hotspot coverage, higher states, other boards, long-duration thermal behavior, or a performance improvement. Sensor failure/staleness/hold cases remain host-policy tests; only high-temperature and unchanged-reading behavior were exercised on hardware.

Prepared with Codex assistance.

With a T8122 ceiling from one to five, the generic fallback calculation
selects that same state as both ceiling and fallback. Increasing the
experimental ceiling therefore prevents thermal On/Hold from returning
to the default state two.

Use the T8122 default ceiling as the fallback while preserving lower
requested ceilings and other SoCs. Keep thermal Off behavior unchanged.
Cover overheating, failed, missing, stale and stuck readings, and hold
mode. Preserve the current M3 Max thermal-zone requirements.

The host suite passes 58 tests with compiler warnings denied. Restoring
the old fallback calculation fails the four new tests. Full kernel
build and higher-clock hardware qualification remain pending.

Assisted-by: Codex:GPT-6
@GehrmannSolutions

Copy link
Copy Markdown

A data point for rebasing this: on integration/aurora 4fdd0fc (7.2.11), the commit cherry-picks cleanly. It needs two paths changed, because the M3 modules now live under crate::m3:

  • m3_thermal_policy.rs: crate::t8122_knobs::PSTATE_CAP → crate::m3::t8122_knobs::PSTATE_CAP
  • m3_adt_config.rs: crate::m3_thermal_policy::safe_cap → crate::m3::m3_thermal_policy::safe_cap

With those changes and arch/arm64/configs/asahi.config (DRM_ASAHI_M3_T8122=y), the full kernel builds here (Clang, -j4). I haven't booted it yet: that needs a boot.bin with the 7.2 J613 DTB, which we'll have after this week's move to the packaged boot chain. Note: #317 touches the same fallback.

(Written with TARS, my Claude Code agent.)

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.

2 participants