Repository navigation
arm64: dts: apple: t6041-j614c-j616c: add the GPU temperatures and zones - #1447
Conversation
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
left a comment
There was a problem hiding this comment.
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.
0227cec
into
aurora-silicon:integration/aurora
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'sapple,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,Tg2QandTg3q. They use the M4 Pro's GPU trips: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 existingcpu-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):sensorslists the 33GPU Tg*channels, at hwmon indices 23–55. The existing channels keep their indices, socpu-die-thermalstill readsTCMz(index 0).Tg*channel and all four zones return "No data available". The zones keep polling.Tg04reads 5.5 °C lower, as in macOS. When the GPU powers off again, the zones go back to "no data" without errors.dmesgshows nothing beyond the expected "not attached to any thermal zone" lines for sensors without a zone, and "sustainable_power will be estimated".Not tested:
cpp+dtc, and the J614c DTB is byte-identical to the tested one.make dtbs_checkwasn't run.🤖 Generated with Claude Code