[scottjones]

Summary

Gary's camera fix in #199 makes the 13-inch M3 Air (J613) use temporal filter 0 on ISP firmware 14.7, because filter 1 delivers no frames there. The 15-inch (J615) has the same sensor and ISP configuration, so this applies the same workaround to it:

-  if (of_machine_is_compatible("apple,j613") &&
+  if ((of_machine_is_compatible("apple,j613") ||
+       of_machine_is_compatible("apple,j615")) &&
       isp->fw_compat == ISP_FIRMWARE_V_14_7 &&
       isp->temporal_filter == 1)

t8122-j615.dts includes isp-imx558-cfg0.dtsi and sets apple,platform-id = <18> and apple,temporal-filter = <1>, exactly as t8122-j613.dts does.

Evidence

• Untested on a J615: we don't have one. A volunteer with a 15-inch Air will test it once a fresh install works.
• On the J613, the media: apple: isp: restore J613 camera capture on 14.7 firmware #199 series on 7.2.11 captured 1920x1080 NV12 at 30 fps, where it timed out before.
• The ISP driver builds with W=1 and no new warnings. checkpatch is clean.

Merge Danger

Door: two-way

Blast Radius: J615 camera

It only changes J615 boards with ISP firmware compatibility 14.7 and filter 1. On any other firmware the J615 keeps its device-tree filter.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Low impact] The PR appears safe to merge; no actionable defects were found.

Summary

Extends the existing J613 camera workaround to J615. On firmware compatibility 14.7, the driver replaces temporal filter 1 with filter 0.

• M3 Air cameras use filter 0 on firmware 14.7.

_{Reviews (1) · Last reviewed commit: "media: apple: isp: use temporal filter z..." · Reviewed by Greptile}

[chriskearney]

Reviewed 7bdc743. The scope looks right: J613 and J615 both use isp-imx558-cfg0.dtsi, platform-id 18 and temporal-filter 1. The fallback remains limited to firmware compatibility 14.7 and filter 1; other boards, firmware versions and explicit filter choices retain their behavior.

I compiled isp-drv.o with W=1 and exercised the actual quirk body across 45 board/firmware/filter combinations under ASan/UBSan. All passed; four deliberately broken guards failed their controls. CI is green.

No source blocker. This is source/build approval, not J615 camera qualification. A J615 owner still needs to check camera startup and repeated captures, including the fallback log and absence of ISP faults. I don’t have a J615 available to do that.

Reviewed with Codex.

[maralcbr]

Thanks @scottjones. Re-checked 7bdc743 against integration/aurora.

• t8122-j615.dts:18,239-243 and t8122-j613.dts:18,227-231 match: isp-imx558-cfg0.dtsi, platform-id 18, temporal-filter 1. The root compatible is apple,j615, so of_machine_is_compatible() can't catch another T8122 board.
• The guard still needs fw_compat == ISP_FIRMWARE_V_14_7, which only apple,firmware-compat = <14 7 0> produces (isp-drv.c:369-379). A J615 that reports another compat keeps its DT filter, so the worst case is "the quirk doesn't apply", not a wrong override.
• Nothing in tools/ or CI greps the old "J613 firmware 14.7" log line, so the message change is safe.

Policy: this does change J615 behaviour by default (filter 0 instead of the DT's 1), but it's disclosed, limited to J615 on 14.7, and the same call we made for J613 in #199. Fine to land on edge.

Before we call the J615 camera working: startup, repeated captures, the fallback log line and no ISP faults on a real J615.

[joshuaswarren]

Hand build of the integration/aurora tip 7b96998 (contains the merges of this PR and #199, #202, #203, #204). Package release 7.2.11-tip-ARCH+, package sha256 52830bb4538e8e8f5344eacff87fbdb9ab26cc553540c36e993ba4e097561c23.

Tested so far (one-shot boot only, stock untouched):

machine	boots	result
14-inch M2 Max	yes (candidate boot 3c4b9246, return 1beecd62)	smoke equal to stock; omarchy-m-test 0.1.13: https://omarchy-m-testing.org/reports/6qHb7QcJkwg2Ref7zubzgZuA (stock reference: https://omarchy-m-testing.org/reports/RVXdswZ8LJoUJKF7vRh2KAHf)
13-inch M1	pending — machine reserved for an all-night test run; will add a line when it ran
16-inch M1 Max	pending — same

CI on this PR: 9 pass, 4 skipped (attest, KUnit, boot, package).

Regressions: none found. dmesg error classes on the candidate boot match the stock baseline (known flakes only: dp-xbar -517 deferrals, brcmfmac join_pref/assoc noise, Bluetooth codec-capabilities -110). m-test check list identical to stock except two tool-level deltas, neither a functional failure: (1) hardware.drivers counts apple,mesa-fingerprint unclaimed on the tip (the node exists, no functional impact seen); (2) sep.attach reads SKIP because the SEP diagnostics ABI moved 1 -> 2 and the tool's reader expects 1 — the driver itself is up on the tip (apple_sep loaded, SEP platform profile T6020/J414s, xART scanned, trusted-keys registered, endpoints discovered), and the audio.microphone checks still pass.

Not tested: M3 paths (this PR's T8122-without-G15 build path is M3-family; the M3 Pro GPU startup in #202 and the J615 camera path in #203 compiled and booted in this build on M1/M2 but their M3-only code paths were not exercised — no M3 machine in this lab).