Repository navigation
arm64: dts: apple: t6041-j614c-j616c: add the keyboard backlight - #1464
Merged
DjDeveloperr merged 7 commits intoNov 10, 2026
Merged
DjDeveloperr merged 7 commits into
DjDeveloperr merged 7 commits into
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>
The M4 Max laptops leave the PWM controller off and describe no keyboard backlight. Their ADTs (J614c read from the running machine, J616c from its 26.6.2 dump) have the M4 Pro's: /arm-io/pwm0 at 0x229040000 with one kbd-backlight channel, reg 0, at default-hz 25000. Describe it as the M4 Pro boards do: a pwm-leds controller on fpwm0 channel 0 with a 40 us period, and fpwm0 enabled. 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.
…n#1464 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.
This was referenced Nov 10, 2026
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 source-review findings. The pwm-leds node and fpwm0 enable match the established M4 Pro wiring: channel 0, 40000 ns period (25 kHz), white keyboard-backlight function, max brightness 255. The shared SoC already defines this PWM controller, and this adds no brightness write or policy override. The stated J614c ADT and brightness/desktop tests support the board wiring; J616c hardware remains untested. Merge should wait for the exact-head DT schema and host-test 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.
DjDeveloperr
merged commit Nov 10, 2026
98c0a08
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 M4 Max laptops leave the PWM controller off and describe no keyboard backlight. Their ADTs have the M4 Pro's:
/arm-io/pwm0at0x229040000, with onekbd-backlightchannel (reg 0) atdefault-hz25000. That's the J614c's, read from the running machine, and the J616c's 26.6.2 dump.This describes it the same way the M4 Pro boards do: a
pwm-ledscontroller onfpwm0channel 0 with a 40 µs period, andfpwm0enabled.Tested on the J614c:
apple::kbd_backlightregisters with max brightness 255. Writing brightness lights the keyboard, UPower picks it up as its keyboard backlight (KbdBacklightmax 255), and GNOME's keyboard brightness control drives it. These keyboards have no backlight keys. On macOS the ambient light sensor and Control Center set it.Not tested on the J616c.
🤖 Generated with Claude Code