[DjDeveloperr]

Adds the T6050 (M5 Pro/Max) CPU-frequency profile: command-state readback with each transition verified (2 ms timeout), refusing any cluster whose node doesn't declare apple,firmware-managed-thermal, and the binding requires that property for apple,t6050-cluster-cpufreq.

Retargeted 2026-11-09 from the APIF series' t6050/base to integration/aurora, with the version tested on bare metal (the PR #1012 kit's c1127df, carried by Erik Bourget in #944): same driver change, and the binding hunk without the old SPDX rewrite. The previous head is kept as backup/t6050-cpufreq-490ccd572f2f.

Tested (J714sAP, M5 Pro, bare metal under aura Stage 2, kit DT with apple,firmware-managed-thermal on the three clusters)

• policy0/policy6 (M, 300-4380 MHz) and policy12 (P, 300-4608 MHz) bind under schedutil; no busy, completion or "unexpected DVFS state" error over several boots of loads.
• Idle clusters sit at 300 MHz, loaded ones at their top state (time_in_state ~98% in those two).
• Measured clocks (dependent add chain): 2.65 / 1.34 / 1.31 GHz at iBoot's states → 4.29 / 4.38 / 4.60 GHz with WFI idle (arm64: idle: T6050 idles in WFI even with idle=nop #1152). One-thread integer work ×1.6 on M, ×3.4 on P.
• Idle system power (SMC PSTR) 20.1 → 7.2-7.9 W from cpufreq alone (idle still spinning under idle=nop); 2.7-2.8 W with arm64: idle: T6050 idles in WFI even with idle=nop #1152.
• The same driver code (c1127df) runs in the M5 integration set's default SSD boot, alongside pmdomain/soc: apple: T6050 DRAM and fabric floors (PMC voters, CLPC, GPU link) #1324 (DRAM/fabric floors), soc: apple: pmp: start the T6050 PMP on bare metal #1326 (PMP) and arm64: idle: T6050 idles in WFI even with idle=nop #1152.

🤖 Generated with Claude Code

[DjDeveloperr]

Hardware result on the M5 Pro (J714sAP, bare metal under aura Stage 2), with this same driver change as carried in the PR #1012 kit (c1127df) and the kit DT, which sets apple,firmware-managed-thermal on the three clusters:

• apple-soc-cpufreq binds all three clusters: policy0 and policy6 (M, 300-4380 MHz), policy12 (P, 300-4608 MHz), schedutil. No busy, completion or "unexpected DVFS state" error in about four minutes of loads.
• Idle clusters sit at 300 MHz and a loaded one at its top state (time_in_state: 300 MHz plus the top state are ~98% of the run; 69-96 transitions per policy over ~70 s).
• Clock measured with a dependent add chain: M0 2.65 → 4.23 GHz, M1 1.34 → 4.30 GHz, P 1.31 → 3.63 GHz (the P cluster's five other cores were spinning under aura's idle=nop, see arm64: idle: T6050 idles in WFI even with idle=nop #1152). One-thread integer work ×1.6 (M) / ×2.0 (P), 18 threads ×2.7.
• With the T6050 CLPC (pmdomain/soc: apple: T6050 DRAM and fabric floors (PMC voters, CLPC, GPU link) #1324) a busy cluster at its top state also raises the DRAM and fabric floors; 12-thread memcpy 42 → 252 GB/s.

Not tried: lazy verification for the fast-switch path (this profile verifies every transition, so schedutil takes the slow path).

🤖 Generated with Claude Code

[DjDeveloperr]

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.

• apple-soc-cpufreq binds all three clusters under schedutil (0-5 and 6-11 300-4380 MHz, 12-17 300-4608 MHz); idle at 300 MHz, loaded at 2964 / 4608 MHz; no DVFS error. The in-tree T6050 DT already declares apple,firmware-managed-thermal.

🤖 Generated with Claude Code