Skip to content

arm64: dts: apple: t6041-j614c-j616c: add the GPU temperatures and zones - #1447

Merged
DjDeveloperr merged 1 commit into
aurora-silicon:integration/aurorafrom
joske:pr/t6041-gpu-thermal
Nov 10, 2026
Merged

DjDeveloperr merged 1 commit into
aurora-silicon:integration/aurorafrom
joske:pr/t6041-gpu-thermal

Conversation

@joske

@joske joske commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

Now that the 40-core M4 Max GPU runs (#1442), give the J614c and J616c the GPU temperatures and thermal zones the M4 Pro has in t6040-gpu-thermal.dtsi. Until now the M4 Max boards published no GPU temperature at all.

Sensors. The J614c's SMC key table (macOS 26.6.2, read with iSMC) has 33 GPU sensors, Tg*. I took one dump at idle and one under a WebGL load that kept the GPU fully busy. All 33 rose 15–17 °C together, from 43–49 °C to 58–65 °C. Sixteen of them read about 5.5 °C above the other seventeen, both idle and loaded. All 33 go into the SMC hwmon with the M4 Pro's apple,no-data-below-millicelsius = <10000>, because the SMC publishes placeholders while the GPU is powered off.

Zones. There are four, gpu0–gpu3-thermal, on four of the hotter sixteen, spread over the key range: Tg05, Tg1V, Tg2Q and Tg3q. They use the M4 Pro's GPU trips:

  • the power allocator switches on at 90 °C;
  • passive at 101 °C, where the GPU firmware starts limiting itself;
  • critical at 118 °C after three samples.

I don't know which GPU cluster each sensor sits on. Under load the hot sixteen read within 1 °C of each other.

Known limitation. The T6041 CPU OPP tables have no opp-microwatt, so no CPU energy model registers. The power allocator then has no power actors, so the passive trips shed nothing. That applies both to these zones and to the existing cpu-die-thermal. On the J614c I confirmed it with an all-core load: the CPU clocks never dropped, and a test kill stopped the run at 114 °C. Until an energy model lands, these zones report GPU temperature and enforce the critical trip. I'm working on the energy model separately: copying T6040's values throttles correctly, but the sustainable power has to be measured first, and on the J614c that is tangled up with the SMC keeping the fans at minimum under Linux. So it isn't in this PR.

Testing on the J614c (linux-aurora built from a82a1eb plus #1442's commits; the DTB was built from this dtsi and installed through update-m1n1):

  • sensors lists the 33 GPU Tg* channels, at hwmon indices 23–55. The existing channels keep their indices, so cpu-die-thermal still reads TCMz (index 0).
  • With the GPU idle and powered off, every Tg* channel and all four zones return "No data available". The zones keep polling.
  • Under 25 s of Vulkan compute, all four zones read real temperatures, 45.6 → 46.6 °C. The base sensor Tg04 reads 5.5 °C lower, as in macOS. When the GPU powers off again, the zones go back to "no data" without errors.
  • dmesg shows nothing beyond the expected "not attached to any thermal zone" lines for sensors without a zone, and "sustainable_power will be estimated".

Not tested:

  • The J616c. It shares the dtsi, and its DTB compiles, but it isn't booted. Its SMC should have the same keys, but I haven't checked.
  • Rebased onto c1c3dc5, both DTBs compile with cpp + dtc, and the J614c DTB is byte-identical to the tested one. make dtbs_check wasn't run.

🤖 Generated with Claude Code

The M4 Max boards publish no GPU temperature, and no thermal zone
watches the GPU. Now that the GPU runs on 25G83, add both, as the M4 Pro
has them (t6040-gpu-thermal.dtsi).

The J614c SMC key table (macOS 26.6.2) has 33 GPU sensors, Tg*. Under a
WebGL load that kept the GPU fully busy, every one of them rose 15-17 C
together, from 43-49 C idle to 58-65 C. Sixteen read about 5.5 C above
the other seventeen, both idle and loaded. Publish all 33 through the
SMC hwmon, with the M4 Pro's no-data threshold for the placeholders the
SMC reports while the GPU is powered off.

Add four GPU zones, on four of the hotter sixteen spread over the key
range (Tg05, Tg1V, Tg2Q, Tg3q), with the M4 Pro's GPU trips: the power
allocator switches on at 90 C, sheds CPU power from 101 C, where the GPU
firmware starts limiting itself, and the zone shuts down at 118 C after
three samples. Which GPU cluster each sensor sits on is not known; under
load the sixteen read within 1 C of each other.

The T6041 CPU OPP tables carry no opp-microwatt yet, so no energy model
registers and the power allocator has no CPU power actors: until they
do, these zones report the GPU temperature and enforce the critical
trip, but their passive trips shed nothing. The same holds for the
existing cpu-die-thermal zone. Like it, the GPU zones leave
sustainable-power to the allocator's estimate.

Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@DjDeveloperr DjDeveloperr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking source-review findings at ed72121. Independently compared the base/head temperature-node ordering: all 22 existing temperature channels retain their indices; the four zone references resolve to Tg05/Tg1V/Tg2Q/Tg3q at indices 23/39/46/54; all 33 added channels use the 10000 mC no-data threshold. The parent SMC node supplies #thermal-sensor-cells = <1>, and macsmc-hwmon preserves indexed channels when a key is unavailable, preventing a missing key from shifting these references onto another sensor. Powered-off placeholders return ENODATA via the existing driver path. Trip temperatures, hysteresis and critical-samples match the established T6040 GPU policy, with CPU references adjusted for T6041's six-core P clusters.

The missing CPU energy model/passive cooling capability remains a documented limitation, not something this PR fixes. J616c hardware sensor availability remains unverified; J614c runtime results are the author's evidence, not independently rerun here. The existing dt-checks workflow validates all Apple DTBs against base/head schemas, so merge should wait for that and host-tests to pass. No image builds were requested or started.

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