Repository navigation
arm64: dts: apple: t6041-j614c-j616c: share the J616c's front camera with the J614c - #1463
Merged
DjDeveloperr merged 5 commits intoNov 10, 2026
Merged
Conversation
The M4 Max boards leave the PMP, its DART, report region and mailbox,
and the PMC disabled, and have no pmp alias, so the loader does not pass
the PMP's values ("FDT: pmp not found in devtree") and nothing starts it.
The M4 Pro boards run it.
Do as they do: the pmp alias, so that the loader copies this Mac's PMP
values from the ADT and enables the PMP; the DART, report region and
mailbox; the PMC with apple,pmp; and the GPU on the PMP's GPU domain,
since a running PMP otherwise treats the GPU as off and holds it at its
lowest state.
On a J614c the loader passes 90 PMP tunables, the PMP firmware starts
("PMP started", report "PMP running (status 0x1)"), the PMC and its CLPC
bind, and the GPU runs compute and render work on pmp_gfx.
Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the PMP running, the cpufreq clusters can take the fast die-temperature limit as the M4 Pro boards do: restore apple,fast-die-effort, which these boards deleted while the PMP did not run (without a running PMP the limit holds each cluster at a third of its power). The ADT (fast-die-ctrl-loop, temp-sensor) is the M4 Pro's: the PMP holds its hot-spot sensors at 110 C, and the sochot maximum is 125 C. On a J614c, four minutes of all-core NEON FMA load with every CPU zone disabled, so the PMP as the only throttle: TCMz settled at 112 C (113 C at most), the cluster limits moved within each second while every cooling state stayed at 0, P0 and P1 ran at 3.5-3.8 GHz, E at 2.59 GHz, and the fans ramped to about 4950/5350 rpm, as on macOS. The SMC sensors the zones read run a few degrees above the PMP's, so the zones move out of its way: switch-on at 112 C and control at 116 C, leaving hot at 120 C and critical at 125 C. Switched on from 75 C they took over from the PMP, trimming far below their control point: with control at 115 C the power allocator held the E cluster at 1.02 GHz. With 112/116 on the J614c, the same load: TCMz at 109-114 C, P0 and P1 at 3.5-3.8 GHz, E at 2.5-2.6 GHz, the zones trimming only briefly above 112 C, and the fans from cold to about 4950/5350 rpm. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…with the J614c The J614c has no ISP: its board file leaves the ISP disabled, without the alias aura looks for or the firmware placeholders it fills. The J614c's ADT (26.6.2, read from the running machine) describes the same isp0 as the J616c's: sensor-type 5 (the IMX958), cam-connections- scheme 0x10, and a firmware of 0xca8000 bytes of __TEXT and 0x1344000 of __DATA that run at 0x100_0000_0000, which iBoot moves each boot and aura copies into the placeholders. So move the J616c's ISP description into the dtsi the two boards share, unchanged. The J616c's device tree stays as it was: its dtb sorted with dtc -s is identical before and after. Signed-off-by: Jos Dehaes <jos.dehaes@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…n#1459 Preserve the original contributor commits and integrate the already-merged NVRAM/SEP changes and preceding reviewed board additions. Resolve shared DTS insertion overlaps without dropping either side.
…n#1463 Preserve original contributor commits and earlier reviewed board additions. Resolve shared DTS insertion overlaps without dropping either side; remove the camera move's trailing empty line.
DjDeveloperr
approved these changes
Nov 10, 2026
DjDeveloperr
left a comment
DjDeveloperr
left a comment
Contributor
There was a problem hiding this comment.
No blocking findings. The ISP alias, firmware reservations/IOMMU ranges, heap, sensor presets and three DART enables are moved unchanged from J616c into the common J614c/J616c include. The board includes are ordered so these definitions still apply to J616c; calibration-dependent firmware addresses remain loader-filled, and the existing disabled SoC node continues to require the handoff. The reported J614c live ADT and camera probe establish the same sensor/platform configuration. Existing J616c properties are preserved by the move; the author's sorted-DTB identity result and J614c capture are not independently rerun here. The original head passed host-tests and full Apple DT schema regression 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.
This was referenced Nov 10, 2026
DjDeveloperr
merged commit Nov 10, 2026
33aebe5
into
aurora-silicon:integration/aurora
2 checks passed
This was referenced Nov 11, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The J614c (MacBook Pro 14", M4 Max) has no camera. Its board file leaves the ISP disabled, without the
ispalias aura looks for and the firmware placeholders aura fills.I read the J614c's ADT (26.6.2) from the running machine. Its
isp0is the J616c's:sensor-type5 (the IMX958), front;cam-connections-scheme0x10;__TEXTof 0xca8000 bytes and__DATAof 0x1344000 bytes, running at 0x100_0000_0000.iBoot moves the firmware each boot, and aura copies its
segment-rangesinto the placeholders on any T6041 board. So this moves the J616c's ISP description (alias, placeholders, ISP node and DARTs) into the dtsi the two boards share, unchanged.The J616c's device tree doesn't change. Its dtb, sorted with
dtc -s, is identical before and after.Tested on the J614c (linux-aurora built from 5186d2e with the open #1458, #1459 and #1461):
apple-ispbinds and registers/dev/video1.ffplay -f v4l2 -video_size 1280x720 /dev/video1shows a live picture from the front camera.apple/isp_2224_01XX.dat, comes from the installer's vendor firmware.🤖 Generated with Claude Code