[scottjones]

Summary

This carries garymeyerca's #134 onto current integration/aurora (7.2.11) so it can merge. The two commits are his, with his author, date and message unchanged. The only addition is my Signed-off-by as carrier. GitHub refused a push to the #134 branch, so the commits are on this omacom branch instead.

 apple_isp_hw_t8122
-  .pmu_base = 0x2d07040000,   # outside the PMGR
+  .pmu_base = 0x2d0704000,    # pmgr 0x2d0700000 + ps_isp_set0 @4000
 apple_isp_probe
+  if J613 && ISP firmware compat 14.7 && temporal_filter == 1
+    temporal_filter = 0       # filter 1 yields no frames on 14.7

Evidence

MacBook Air 13" M3 (J613), OS firmware 14.7, this exact tree on 7.2.11 (with #187's GPU runtime enabled):

• Before: the first use of the camera timed out (IO: timed out on request, never received magic number from firmware).
• After:
  • the probe logs using temporal filter 0 on J613 firmware 14.7, with no ISP timeouts or faults;
  • six ffmpeg captures of 60 frames each, NV12 1920x1080 at 30 fps;
  • display, GPU and audio unchanged on that boot.

Details are in the #134 comment.

Merge Danger

Door: two-way

Blast Radius: J613 camera

The PMU base only changes T8122. The filter quirk only fires on apple,j613 with ISP firmware compat exactly 14.7 and filter 1. J615 sets the same filter in its device tree and may need the same quirk, but it's untested.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

Corrects the T8122 camera power-register address and adds a narrowly scoped J613 workaround.

• J613 cameras use filter 0 on firmware 14.7.
• T8122 ISP firmware receives its updated PMU base address.

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

[maralcbr]

Thanks @scottjones, and thanks @garymeyerca for the original fix in #134. Both changes look right to me, and there are no code blockers.

• The PMU base is now inside the PMGR. T8122's PMGR is at 0x2d0700000 (t8122.dtsi:853) and ps_isp_set0 is at offset 0x4000 (t8122-pmgr.dtsi:967-969), so 0x2d0704000 (isp-drv.c:685) follows the same PMGR + 0x4000 pattern as T8112 and T6030. The old value was 16 times too large.
• The filter quirk is narrowly gated. It only fires on apple,j613, an exact apple,firmware-compat of 14.7.0 (isp-drv.c:338-339) and filter 1 from the DT (t8122-j613.dts:231). It runs before the only consumer at isp-cam.c:541, and an unknown or missing compat leaves the filter alone. A driver quirk fits better than a DT change here, since the problem follows the ISP firmware rather than the board.

tools/aurora-ci/check-commits.py passes locally on both commits. checkpatch's NO_AUTHOR_SIGN_OFF is expected for a carried commit, and the check accepts the carrier's sign-off.

I'll approve once CI finishes: compile, commits, device trees and host tests were still pending when I looked.

Smaller things, none blocking:

• The PMU change isn't J613-only. Every apple,t8122-isp uses that table (isp-drv.c:802), so J504, J433, J434 and J615 get it too. Please widen the Blast Radius line in the PR body to say so. A camera run on another M3 would be welcome, but I don't need it for merge.
• The gate is ISP firmware-compat, not OS firmware. A later OS firmware that still advertises compat 14.7 will also get filter 0. Suggest the comment and log say "firmware-compat 14.7" (isp-drv.c:424, :428).
• Could you add Fixes: f26396997e09 ("media: apple: isp: add t8122 support") to 6b34040? That's where 0x2d07040000 came in, and it'll help when this goes upstream.
• Nit: 4433ef5 says "m1n1 supplies temporal-filter=1", but it comes from t8122-j613.dts:231. Both messages also still say hardware qualification of the rebased source is pending, which your 7.2.11 run on #134 now covers. Fine to leave them as Gary wrote them if you'd rather not reword.

For release, not this merge: your six captures cover J613 on 14.7. J615 sets the same filter (t8122-j615.dts:243) and stays untested, so that's a follow-up for whoever has one.

[maralcbr]

nit: this gates on ISP firmware-compat, not the OS firmware version, so "firmware-compat 14.7" here and in the comment at :424 would be more precise.

[maralcbr]

Right: PMGR 0x2d0700000 + ps_isp_set0 0x4000. Could the commit carry Fixes: f26396997e09 ("media: apple: isp: add t8122 support")?

[maralcbr]

PMU base matches t8122 DT (pmgr@2d0700000 + ps_isp_set0@4000). Quirk scoped to J613 + fw 14.7 + filter 1. Hardware evidence + green CI.

[joshuaswarren]

Kernel CI on three lab laptops (hand-built one-shot boots; all three returned to stock afterwards).

Head tested: 4433ef5 (2 commits, drivers/media/platform/apple/isp/isp-drv.c only, +9/-1).

What was built: a hand-built bootable linux-aurora package, release 7.2.11-pr199-ARCH+ (published edge package config + olddefconfig, LLVM 22, arm64, module-signing config as shipped). Base tree: d8ecb2e, which is an ancestor of this PR's base integration/aurora (be6381f) sitting 22 commits behind it; none of those 22 commits touch drivers/media/, so the ISP driver path is byte-identical between this build base and the PR base. On top of it, this PR's head isp-drv.c verbatim (git blob sha ead021d7c3317ad358e89510a9721de7b784521a, verified against the compare API). So the driver code under test is exactly this PR's; everything outside the ISP driver is 22 integration commits older than the PR base.

CI on this PR (from the checks API): 9 pass (plan, CI self-test, commits, compile, device trees, host tests (tools), host tests (aurora-sep), result, Greptile), 4 skipped (package, KUnit, boot, attest).

Per laptop: stock baseline smoke run, then a single one-shot candidate boot of 7.2.11-pr199-ARCH+, candidate smoke, graceful return to the stock default, protected boot artifacts hash-verified, no pending one-shot. Smoke covers boot (0 failed units), wifi association + gateway reach, input nodes, HID error scan, display backlight set/readback, audio tone playback, ANE driver node, battery; extras cover Vulkan device probe, GL/compute sanity, ALSA card check, GPU dmesg scan.

Machine	Boots candidate	Result
13-inch M1 MacBook Pro (T8103)	yes, boot id d18fa2f0	PASS
14-inch M2 Max MacBook Pro (T6021)	yes, boot id 9e6e0e6a	PASS
16-inch M1 Max MacBook Pro (T6001)	yes, boot id 8377c59b	PASS

Regressions vs each machine's own stock baseline: none found.

• Candidate dmesg error classes: on the 14-inch M2 Max and the 16-inch M1 Max the candidate set is a strict subset of that machine's stock baseline (dp-xbar -517 deferrals, pcieport of_irq, brcmf, Bluetooth hci codec-capability classes — all present on the stock boots too). On the 13-inch M1 the candidate classes are identical to the classes we measured on the same 7.2.11-based candidate for PR 182 (tas2764 parse-devicetree deferrals and the dp-xbar/of_irq classes arrive with the 7.2.11 base tree, not this PR); the spi-hid-apple-of get-report -110 / magicmouse dimensions -110 pair appears intermittently on stock boots as well and is on our known-flake list.
• apple-isp specifically: the driver loads and binds on all three machines (camera nodes /dev/video0 and /dev/video1 present on stock and candidate on every machine) and produces zero apple-isp/isp-drv dmesg lines on both stock and candidate boots — no probe regression from either change.
• One observation not attributable to the PR: on the 14-inch M2 Max, wlan0 did not associate on either today's stock baseline boot or the candidate boot (iwd active and scanning, wired Ethernet up, gateway reachable; earlier boots of the same stock kernel did associate). Identical state before/after, cause not determined.

What this does not test: none of these machines is a J613 or T8122, and none runs firmware compatibility 14.7 — both changes are gated off on these machines (the PMU base fix is in the T8122 hw table; the temporal-filter workaround requires apple,j613 + fw compat 14.7 + filter 1), so actual camera capture on the targeted hardware is unverified here; no capture was attempted. No M3 hardware in the fleet, no suspend/resume, no cold power-on.

[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).