[erikwb]

On integration/aurora (7.3), a J713 (MacBook Air 13" M4) boots, but has no GPU and no display. Both failures come from one upstream change.

What breaks

7.3 brought in 233b555 ("arm64: mm: Treat all devices as dma-coherent when CLIDR_EL1.LoC == 0"). T8132 reports LoC == 0, so arch_setup_dma_ops() now makes every device coherent, including ones whose DT node says dma-noncoherent.

The J713 G16 and DCP paths were brought up and qualified on non-coherent DMA only. They refuse coherent devices on purpose:

• GPU: asahi_g16_dma_unsupported() (drivers/gpu/drm/asahi/g16/glue.c) fails admission with G16: unsupported coherent, IOMMU or custom DMA path → -EINVAL, so there's no render node.
• Display: apple_dart_dcp_shared_pair() (drivers/iommu/apple-dart-dcp-shared.h) returns -ENODEV for the DCP D451 memory callback. The log shows DCP callback D451 … dispatch failed: -19 → Retained DCP session quarantined → IOMFB startup failed: -19, so there's no apple-drm.

The scanout allocator (apple-dart-dcp-scanout.h) and dcpext_scanout.c have the same check.

Older SoCs and the other Apple drivers don't check coherency, which is presumably why J700 and M4 Pro testing on 7.3 didn't hit this. #400 hadn't been booted on a J713 before this.

Fix

0. T6040 DT. Drop dma-noncoherent from the J616s display-subsystem. The J616s display has only run coherent, so it stays that way under patch 1.
1. arm64: mm. When LoC == 0, keep the coherent override, but skip it for a device whose own firmware node explicitly says dma-noncoherent. Devices without that property behave exactly as upstream 7.3 does.
2. J713 DT. Mark gpu, dcp, dcp/piodma and display-subsystem dma-noncoherent. These are the devices those checks look at.

This brings back the DMA path the J713 code was qualified on, without touching Eryk's drivers. The alternative is relaxing the coherency checks in G16 and DCP. That would change the memory attributes the firmware sees (for example, apple_dart_dcp_alloc adds IOMMU_CACHE for coherent devices), and it needs someone who knows why those checks are there.

Effect on T6040: none. t6040.dtsi display-subsystem had dma-noncoherent, but under the LoC override it never took effect, and the J616s display has only ever run coherent, as have its dcp and piodma. As @jgoyvaerts asked, patch 0 removes the property, so the series doesn't change J616s. A non-coherent J616s display can be qualified separately.

I don't expect patch 1 to go to mainline as it stands. Will's commit message treats a non-coherent device on a LoC == 0 system as a firmware bug, and warns about it. It's meant as an Aurora carry until G16/DCP either support the coherent path or are confirmed to need non-coherent DMA.

Testing

J713, 8-core GPU, integration/aurora 420a1c8 + these two patches + the #389 8-core hash:

• No "treating as coherent" warning for gpu, dcp, piodma or display-subsystem. Every other device still gets it, as on stock 7.3.
• apple-dcp 30ae00000.dcp: IOMFB startup complete: 255 callbacks, 2560x1664
• asahi-g16 302600000.gpu: G16: firmware at READY, starting the backend
• OpenGL renderer string: Apple M4 (G16G B0) with Mesa 26.3.0-devel (91ac7e2), Hyprland running.
• Wi-Fi, Bluetooth, keyboard and trackpad work. No SErrors.

I also tested a plain revert of 233b555 on the same base, and it gives the same result.

Rebased onto 23827fe (2026-10-30). The base now reports the LoC rule once per boot (49b22c6). Patch 1 keeps that and words the notice as "treating devices not marked dma-noncoherent as DMA coherent". The per-device line stays at debug level. The rest is unchanged from the tested head, apart from patch 0, which was added after review. On the current base:

• checkpatch --strict is clean;
• arch/arm64/mm builds with W=1 at every commit;
• CHECK_DTBS gives the same 11 diagnostics as the base on all six T8132 DTBs and both T6040 DTBs;
• after the series, the J713 nodes are the only Apple nodes marked dma-noncoherent.

Questions

• @erykwieliczko / @RyanTheTide: are G16 and DCP non-coherent-only on purpose? Is the M4 DMA fabric actually coherent with the CPU caches? If it is, the right long-term fix is qualifying the coherent path, and these annotations can go.
• On T8132, stock 7.3 prints CLIDR_EL1.LoC == 0, treating as coherent once per device, about 380 lines per boot. It's harmless, but worth knowing about.

[RyanTheTide]

I checked the LoC-zero override, the explicit firmware-property guard and each device that the J713 GPU and display admission paths inspect. The ordinary LoC-nonzero path is unchanged. This remains an Aurora carry with a wider arm64 effect, so the reference-Mac checks matter. The attribution check found no additional Gravity-derived implementation.

I pushed Ryan fixup 90c0d00eb5379 to permit dma-noncoherent in the GPU binding. That fixes the new J713 schema diagnostic. The J713 and J616s targeted binding/DTB checks now have no diagnostics, and the fixup is checkpatch-clean.

The combined tree passed apple-dcp 63/63 and Asahi KUnit 86/86. The first defconfig plus asahi.config WERROR build passed; the shipping and final fixup-tree builds are still running. This is not merge-ready until the M1 Pro/M2 one-shot checks pass and the common config dependency in #438 is reviewed.

[RyanTheTide]

Final software gates now pass on the combined tree containing these heads and the proposed common config correction in #438. Both defconfig plus asahi.config and the Fedora-base recipe build Image, modules and DTBs with WERROR enabled. The Fedora recipe also covers KUNIT=m. Every requested asahi.config setting survives resolution. Asahi KUnit passes 86/86 and apple-dcp host tests pass 63/63. The targeted J713/J616s binding and DTB checks have no diagnostics.

The GPU binding fix is included and final source-style checks are clean. This remains not merge-ready until the M1 Pro/M2 candidate boots pass and #438 is reviewed.

[RyanTheTide]

M2 no-regression qualification now passes with this head in the combined source tree 031f7dec92a1bef6b72509b08c5c597f50474adb. The approved one-shot ran 7.3.0-aurora-t3028. A native Apple GPU compute/readback check verified all 4096 words, the checked kernel fault counters stayed at zero, and device counts, active services and SELinux enforcing matched the baseline. This uses the installed system Mesa to exercise the candidate kernel.

The machine is back on 73w, where the same check passes again. The test kernel, its GRUB entry and fallback units have been removed. The saved default, boot.bin and pinned DTB setting are unchanged.

The M1 Pro candidate check and the #438 common-config review are still outstanding, so this remains not merge-ready.

[RyanTheTide]

Final qualification for 90c0d00eb53799ed927526d90a4425ec07a9baa6. The combined test source is 031f7dec92a1bef6b72509b08c5c597f50474adb, tree 36854d3a72e4efdf2c352166498ab436adaf3c48.

Both defconfig plus asahi.config and the Fedora-base shipping recipe pass the full Image/modules/DTB build with WERROR enabled. Every requested fragment value survives olddefconfig. Asahi KUnit passes 86/86, apple-dcp host tests pass 63/63, and targeted J713/J616s binding/DTB checks have no diagnostics. Strict source-style checks pass; commit sign-offs are checked separately. The attribution audit found no new material Gravity implementation blocks. Existing GPL-2.0-only Cody Ho and Niklas Sheth credit is preserved.

The same candidate image passed approved M1 Pro and M2 one-shot smoke checks against fresh normal baselines. Native GPU compute/readback verified all 4096 words on each device, kernel fault counters stayed at zero, and baseline devices, active services and SELinux enforcing were preserved. Both machines are back on 73w with the checks passing again. Test kernels, task GRUB entries and fallback units are removed. The saved defaults, stock boot.bin files and pinned DTB setting are unchanged.

Ryan fixup 90c0d00eb5379 permits the standard dma-noncoherent GPU property and removes the J713 schema diagnostic. No code hold remains. Not merge-ready yet because #438 still needs the required common-config review.

[RyanTheTide]

I rechecked the LoC-zero exception and the four J713 nodes that request non-coherent DMA. The exception is limited to devices with an explicit firmware property, but the arm64 code is shared and T6040 already has a matching display annotation. The PR's J713 GPU/display boot is the board proof. Earlier M1 Pro/M2 checks used a different combined tree.

The stacked kernel at 5b6f5515e2f8 passed both full universal and Fedora-base WERROR builds (Image, modules and DTBs); both preserve all 131 common-config settings. ARM64 16 KiB KUnit passed 275/275. DCP host tests passed 63/63, and the PMGR and radio SID checks passed. The M4 host suite has the same five failing groups as the pinned base (18/23 on each); the AFKv2 HPD harness also fails on both. These are recorded failures, not a full host-suite pass. All six T8132 DTBs were checked: 13 schema diagnostics against 11 on the base, with exactly two new DCP dma-noncoherent binding errors from #429. The seven targeted binding checks passed. These software gates do not replace the required shared-code boots.

The full J713 DTB check rejects dma-noncoherent on the DCP controller and its piodma child under apple,dcp.yaml. Please allow the annotation at both levels and rerun the full check. The GPU binding addition does not cover these DCP nodes. The base has 11 diagnostics and this stack has 13; these two DCP errors are the only additions.

Keep it behind the shared-code regression boot on Neo, with display/GPU compute, cache/DMA fault checks and a return to the normal kernel. Include the J616s display owner in rollout because its existing annotation takes effect too. Merge with the reviewed #394 common recipe before the #449 sleep combination.

[RyanTheTide]

The reviewed head 90c0d00eb537 applies cleanly on the qualified base. The J713 loaded-image KUnit case now runs and passes with G16 explicitly enabled in the test configuration.

On integration/aurora at 421e314 with shared #438 and #456, DCP is PASS (63/63). KUnit has 905 passes and 1 policy skips. Universal WERROR is PASS; Fedora-base WERROR is PASS.

Software gates pass; hardware and shared #438/#456 review pending. The operator reports #456 passed all 63 host groups with stock make 3.81 and GNU Make; this worker did not rerun native macOS on the assembled base. Hardware still needed: Neo LoC-zero DMA/GPU/display; M1 Pro/M2 regression and separate J713 proof.

[erikwb]

Added 88a7baebcc6f: apple,dcp.yaml now allows dma-noncoherent on the DCP controller and on its piodma child.

I reran the check on all six T8132 DTBs (CHECK_DTBS=y), and the result is now 11 diagnostics, down from 13. The two DCP dma-noncoherent errors are gone, and the other 11 match the base. dt_binding_check for display/apple,dcp.yaml is clean, as is checkpatch --strict.

[erikwb]

@jgoyvaerts this makes the J616s display-subsystem non-coherent again on 7.3, as its node in t6040.dtsi asks. Does the J616s display still come up with it? If it should stay coherent, the property can come out of t6040.dtsi.

[jgoyvaerts]

Not tested with it. That annotation has never taken effect on J616s: the display has only ever run coherent, on 7.3 with the LoC override, so this would be a new configuration rather than a return to 7.2. It would also be a mix, because dcp and piodma stay coherent here. Probe paths look unaffected, but scanout buffers would change (NO_CACHE, WC dumb buffers). Please drop dma-noncoherent from display-subsystem in t6040.dtsi as part of this PR. That keeps #429 a no-op for J616s, and we can qualify non-coherent separately if it's ever wanted.

[erikwb]

Thanks. Done: the new first patch drops dma-noncoherent from the display-subsystem in t6040.dtsi. After the series, only the J713 nodes are marked, so #429 changes nothing on J616s. CHECK_DTBS matches the base on both T6040 DTBs. I also corrected the two commit messages that pointed at the T6040 node.

[erykwieliczko]

Merging as it is, no changes. This comment is from Claude Opus 5.5, working for Eryk, not from Eryk himself.

It still merges cleanly, and integration/aurora still has the blanket CLIDR_EL1.LoC == 0 override in arch_setup_dma_ops(), so this is still needed. The J713 display depends on it. Ryan's and Erik's commits are untouched.

Testing

• On Eryk's J713, in a test kernel with the other J713 PRs and Mesa aurora-wip 05ddb00f5ca9: glmark2-wayland --validate passes every scene with a reference, and a WebGL shader and YouTube ran with no GPU or DCP faults.
• Built together with the rest of this batch on integration/aurora (arm64: Image, modules, DTB).

---

🤖 Written by Claude Opus 5.5 (in Claude Code) for Eryk.