Skip to content

arm64: dts: apple: t6041: Chapel PMIC, PMU RTC and 24 cache planes on the J616C - #994

Merged
RyanTheTide merged 3 commits into
aurora-silicon:integration/aurorafrom
AxxzyWasTaken:j616c-dt-deltas
Nov 6, 2026
Merged

RyanTheTide merged 3 commits into
aurora-silicon:integration/aurorafrom
AxxzyWasTaken:j616c-dt-deltas

Conversation

@AxxzyWasTaken

Copy link
Copy Markdown
Contributor

Replaces #914, reworked as deltas on the J616C device tree that landed through astaff's series, as asked in review. Only what that tree doesn't have is left, three commits:

  • Chapel PMIC: the tree inherits the J616s's Abbey at nub-spmi0 0xe, which doesn't exist on this machine. The J616C ADT (macOS 26.6.2, mBoot-18000.161.10) has a Chapel at 0xb (spmi-chapelL1-b), so the SMC RTC offset, boot stage, panic count and shutdown cells point at nothing. They're at the Abbey offsets on the Chapel, as are the RTC alarm registers (ADT info-rtc_alarm_*). This adds the Chapel with its cells and its PMU RTC, adds apple,chapel-pmic to the spmi-nvmem binding (t6030 and t6031 already use it), and keeps nub-spmi0's interrupt controller, which the RTC alarm needs.
  • Cache: the MCC node is left disabled with 16 planes. This lists the 24 planes every T6041 has (up to eight AMCCs of four planes, six on the binned part, ADT amcc-enable-mask 0x3f), using the limit from soc: apple: mcc: allow up to 32 cache planes #911, and enables it on the J616C.

Dropped from #914, already merged or not needed: the six-core P clusters, power domains, sensors, board firmware names, MTP resets, and the aop and mtp aliases are in the merged tree. The spmi1 and spmi2 PMICs aren't needed: the merged tree deletes those buses and nothing there has a binding. The USB3 per-unit tunables are left out too: they're per-machine calibration values and the merged tree's differ from this Mac's, so a device tree can't hold one right set. They're worth a separate look, probably with the boot loader filling them in.

The RTC child of the Chapel needs #930 to be populated.

Testing (J616C, 14-core M4 Max): the PMIC, RTC and 24-plane values have run daily on this Mac on 7.3 since 4 Nov, from our own tree in the old layout: system level cache allocation enabled on 24 planes, SMC RTC, reboot and poweroff, and a 45 s timed wake from sleep on the PMU RTC (rtc1, with #930). This exact rebased tree hasn't been booted. It compiles, its only differences from integration/aurora in the built tree are the MCC, nub-spmi0 and PMIC nodes above, and dtc gives the same warnings as before, no new ones. dt_binding_check wasn't run.

t6030.dtsi and t6031-die0.dtsi already use apple,chapel-pmic, and the M4
Max's main PMIC is a Chapel too.

Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
The tree inherits the J616s's Abbey at 0xe on nub-spmi0, which doesn't exist
here: the J616C ADT has a Chapel at 0xb (spmi-chapelL1-b), so the SMC RTC
offset, boot stage and shutdown cells point at nothing. The cells and the RTC
alarm registers are at the Abbey offsets (ADT info-rtc_alarm_*).

Describe the Chapel with those cells and its RTC, and keep nub-spmi0's
interrupt controller, which the RTC's alarm uses.

Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
T6041 has up to eight AMCCs with four cache planes each, six on the binned
part (ADT amcc-enable-mask 0x3f). List the 24 planes every T6041 has, which
the MCC driver takes since the plane limit went to 32, and enable it on the
J616C, where it was left disabled.

Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
AxxzyWasTaken added a commit to AxxzyWasTaken/linux that referenced this pull request Nov 5, 2026
The J616C device tree is now in integration/aurora, without the J616s board file that carried the ISP setup, so take its files and add the ISP here: the alias, the firmware placeholders the loader fills, the node and its DARTs. The Chapel binding moved to aurora-silicon#994.

Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
@RyanTheTide

Copy link
Copy Markdown
Contributor

Merge train (MTR, 06/11): merging. I reviewed it. Everything is in t6041.dtsi / t6041-j616c.dts plus one binding enum, so no other Mac's tree changes, and dt_binding_check is clean. We have no M4 Max, so the hardware proof is the author's daily J616C runs on these values: the 24-plane MCC, the Chapel RTC and the timed wake.

Gates: test merge 2d3579ef = integration/aurora 11eccbe + #1005 #994 #930 #658 #992 #1006 #1007 #1008 #531 (#992 has since landed on its own); base 11eccbe.

  • KUnit: drm/apple 112/113 (1 skip); Rust (asahi, incl. asahi_g17_validation_pages) 200/201 (1 skip); arm64 apple-isp-*, apple-pmc, apple-pmgr-pwrstate and thunderbolt 137/138 (1 skip).
  • W=1 on drm/apple, media/apple/isp, pmdomain/apple, thunderbolt and nvmem/apple-spmi-nvmem: 0 new warnings.
  • dt_binding_check (apple,dcp, apple,dart, apple,t8132-isp, apple,spmi-nvmem, apple,pmc): 0 new.
  • Host tests run-host-tests.py 185/185; apple-dcp selftests 86/86.

Hardware (7.3.0-aurora-mtr1106a, one-shot boots, fleet recipe):

  • J616s (M4 Pro) vs fleet17: 0 kernel errors, 0 AVC, 0 failed units; eDP + DP-2, Wi-Fi, Vulkan G16S. Camera NV12 1080p and 720p, and P010 720p, streamed 30 frames each, with no ISP errors. vkcube OK; glmark2 6617/6738/6683 vs fleet17 6646/6555/6664.
  • Neo (A18 Pro), two boots vs fleet16: 0 kernel errors, 0 AVC, os_uuid pin present; eDP, Wi-Fi, Vulkan G17P. Camera NV12 1080p and 720p, no ISP errors. vkcube OK; glmark2 2718/2729/2726/2725 vs fleet16 2043–2108; 0 GPU faults.
  • Both Macs were restored to their default kernels afterwards.

@RyanTheTide
RyanTheTide merged commit 72ab902 into aurora-silicon:integration/aurora Nov 6, 2026
AxxzyWasTaken added a commit to AxxzyWasTaken/aurora-installer that referenced this pull request Nov 9, 2026
main admits the J616C without a Stage 1 caution, because Aurora has run
on one. It has, but only with separately built kernel and aura: this
installer has not installed it, and the J616C device tree it delivers
(aurora-silicon/linux#994) has not been booted on one yet.

Give the J616C its own caution, in Stage1Caution.swift and mirrored in
supported-models.json, so the owner acknowledges the risk and the
recovery steps before installing. The tests move j616c from the boards
without a caution to the cautioned ones.

Signed-off-by: AxxzyWasTaken <axxzytte@gmail.com>
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