Skip to content

arm64: dts: apple: t6041-j614c-j616c: add the SD card reader - #1465

Merged
DjDeveloperr merged 9 commits into
aurora-silicon:integration/aurorafrom
joske:pr/t6041-j614c-sdreader
Nov 10, 2026
Merged

DjDeveloperr merged 9 commits into
aurora-silicon:integration/aurorafrom
joske:pr/t6041-j614c-sdreader

Conversation

@joske

@joske joske commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

The M4 Max laptops describe only the Wi-Fi port of their PCIe controller, so nothing sits behind the SD slot's root port (00:01.0).

Their ADTs have the M4 Pro's reader. I read the J614c's from the running machine and the J616c's from its 26.6.2 dump:

  • apcie0/pci-bridge1, with PERST on GPIO 5 and CLKREQ on GPIO 1;
  • a pcie-sdreader powered by the SMC's gP19 output;
  • the controller's second interrupt, 1732;
  • dart-apcie1 at 0x211000000, interrupt 1733.

This describes it the same way the M4 Pro boards do:

  • port 1 with the GL9755 (pci17a0,9755) and its supply;
  • the CLKREQ pin;
  • the second interrupt;
  • the reader's DART. t6040.dtsi defines that DART only for T6040, so it goes in the M4 Max boards' dtsi.

Tested on the J614c:

  • The GL9755 enumerates at 02:00.0, and sdhci-pci registers mmc0 with ADMA 64-bit.
  • An inserted 128 GB SDXC card is detected at UHS-I SDR104 and shows up as mmcblk0 with its partition. So card detect works with cd-inverted, as on the M4 Pro.

Not tested on the J616c.

🤖 Generated with Claude Code

joske and others added 9 commits November 10, 2026 13:11
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>
The M4 Max laptops describe only the Wi-Fi port of their PCIe
controller, so the SD card slot has nothing behind its root port.

Their ADTs have the M4 Pro's reader (J614c read from the running
machine, J616c from its 26.6.2 dump): apcie0/pci-bridge1 with PERST on
GPIO 5 and CLKREQ on GPIO 1, a pcie-sdreader powered by the SMC's gP19
output, the controller's second interrupt (1732), and dart-apcie1 at
0x211000000 with interrupt 1733.

Describe it as the M4 Pro boards do: port 1 with the GL9755 (pci17a0,9755)
and its supply, the CLKREQ pin, the second interrupt, and the reader's
DART, which t6040.dtsi has only for T6040.

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.
…n#1465

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 DjDeveloperr left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No blocking source-review findings. Port 1's reset/enable GPIOs, CLKREQ pin, GL9755 IDs, bus ranges, IOMMU stream mapping, second PCIe interrupt, and inverted CD/WP properties match the existing M4 Pro reader description. The new DART matches the existing T6040 node's physical address 0x411000000, span 0x20000, and IRQ1733; T6041 does not include that T6040-specific node, so defining it here avoids duplication. The PR body quotes an ADT address 0x211000000 while the DT reg uses 0x411000000; the latter agrees with the established SoC description and author's successful J614c enumeration, so this appears to be a description/address-space typo rather than a code defect. J616c is still untested, and the stated SD test establishes enumeration/card detection rather than write/throughput qualification. Merge should wait for exact-head 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.

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