[joske]

Follows #1452. This PR runs the PMP on the M4 Max laptops and lets its fast die-temperature loop lead the CPU throttling, as the M4 Pro boards do. The #1452 zones then act only as a backstop.

Before: the M4 Max boards leave the PMP, PMC and their nodes disabled, and they have no pmp alias. So aura doesn't pass the PMP values ("FDT: pmp not found in devtree"), nothing starts the PMP, and apple,fast-die-effort is deleted from all three cpufreq domains. Without a running PMP, that limit holds each cluster at a third of its power.

Commit 1, run the PMP: this adds the M4 Pro's setup:

• the pmp alias;
• pmp_dart, pmp_report and pmp_mbox;
• pmc with apple,pmp;
• the GPU on pmp_gfx.

On the J614c, aura passes 90 PMP tunables. The PMP starts ("PMP started", "PMP running (status 0x1)"), the PMC and CLPC bind, and the GPU runs compute and render on pmp_gfx.

Commit 2, let the PMP's fast die loop lead:

• apple,fast-die-effort is restored. The ADT's fast-die-ctrl-loop and fast-die-ctrl-ce-map are byte-identical to the J614s's: 110 °C target, same lanes.
• The CPU zones move out of the PMP's way: switch-on 112 °C, control 116 °C, hot 120 and critical 125 unchanged. The SMC sensors read a few degrees above the PMP's. Switched on from 75 °C, the power allocator trims far below its control point and takes over from the PMP.

Measured on the J614c, four minutes of 16-thread NEON FMA load each:

	#1452 zones only	zones 75/115 + PMP	PMP alone (zones disabled)	this PR (112/116 + PMP)
TCMz	109–111 °C	109–113	112, max 113	112, max 113
P0 / P1	3.3–3.8 GHz	3.6–3.9 / 3.6	3.6–3.8 / 3.5–3.8	3.6–3.8 / 3.5–3.8
E	2.59 GHz	1.02	2.59	2.59
Zone cooling states	up to 15	6–10	0	0–2
Fans	~4100–4450 rpm	~4950/5350	~4950/5350	~4950/5350

macOS, under the same load: TCMz 105–110 °C and fans at about 4950/5350 rpm.

With this PR the cluster limits move within each second while the zones' cooling states stay at 0–2. So the PMP does the fast control, as on macOS and the M4 Pro.

Not tested: the J616c. It shares the dtsi. If its PMP didn't start, the fast-die fallback would hold its CPUs at a third of their power, and cpufreq warns after 30 s. Its ADT has the same temp-sensor and fast-die-ctrl-loop as the J614c's. Could someone with a J616c (AxxzyWasTaken, astaff?) boot it there?

🤖 Generated with Claude Code

[DjDeveloperr]

No blocking findings after reviewing the shared SoC nodes, current CPU energy/thermal policy, PMC supplier dependency and cpufreq fallback. The pmp alias enables the existing loader tunable handoff, which sets status=okay only after locating the ADT PMP; the PMC apple,pmp link defers until the PMP is bound. Restoring the inherited three fast-die-effort lanes retains the cpufreq driver's limited-power fallback until PMP reports running. Moving the Linux CPU zones to 112/116 C leaves hot/critical trips, three-sample shutdown, sustainable-power values and cooling maps intact. The GPU power-domain vote follows its existing pmp_gfx/ps_gfx lifetime. J614c runtime measurements are attributed to the author; J616c hardware validation remains outstanding. The original head passed host-tests and dt-checks.

Resolved the shared DTS insertion conflicts by merging current integration and the preceding reviewed PRs into this branch, preserving the original contributor commits and all earlier merged changes. Each original patch hunk matched uniquely; the incremental changes are the original PR changes (plus removal of an empty line left at EOF by the camera move). Updated-head CI must pass before merge. Merge this series in order: #1459, #1463, #1464, #1465. No image build or hardware change was started.