[satchlj]

DISP_CPU can report ACTUAL=4 while AUTO_ENABLE is set and TARGET=15. The actual-only readiness check treats that logically active state as off and returns EBUSY, so the J613 display handoff is refused. Use the same active-state rule as apple_pmgr_ps_is_active() in the PMGR provider, keep the loop read-only, and keep every other handoff check.

The captured J613 (T8122) state was 0x1404024f. A diagnostic boot of the Aurora/Omarchy chain with 26.6.2 firmware and this change drove the internal 2560x1664 display (and, with the related GPU fixes, native Apple M3 rendering). This patch carries no diagnostic logging.

The host test runs the production helper over all 512 actual/target/auto combinations plus the captured state, at -O0 and -O2, and is registered with Aurora CI.

[chriskearney]

Reviewed c89018e against 2dd4aab. The read-only readiness predicate matches apple_pmgr_ps_is_active(): ACTUAL=15, or AUTO_ENABLE with TARGET=15. An exhaustive CPU comparison over all 32-bit states found no mismatch; the captured state and the author's -O0/-O2 tests pass. The existing board, 26.6.2 DCP identity/UUID, clock-witness and handoff-marker gates remain intact; J615 remains experimental. No kernel CLI opt-in is added.

Source approval only. Like the provider, this predicate also accepts lower ACTUAL states with AUTO/TARGET=15; independent hardware auto-wake behavior has not been established by our CPU checks. Varying reserved upper bits would strengthen the authored regression (one broad-mask mutant survives its current cases).

The #301/#302 host-test registry overlap was composed locally with both registrations preserved: ManifestTest and both suites pass; dropping either registration fails ManifestTest. That resolution still needs normal integration and full CI/package checks before merge; there is currently no Actions run for this head and no kernel build or physical test in this review. The author's diagnostic boot also included #303–#307, diagnostic bootloaders and manual switches, so it does not qualify these PRs alone or the packaged default path. GPU identity, firmware, J615 and existing thermal/TCMz limits are unchanged.

[satchlj]

@chriskearney Added a small test-only follow-up in d17068f, after your approval of c89018e.

tools/asahi/test-j613-dcp-power.py now crosses all 512 ACTUAL/TARGET/AUTO combinations with 27 unrelated-bit patterns: zero, all set, alternating patterns, and each bit in [31:29] and [27:8] individually. The 13,824 cases retain coverage of lower ACTUAL states accepted with AUTO_ENABLE and TARGET=15, and retain the captured-state controls. No production code changed.

Offline CPU validation on alba:

• The real production helper passes at -O0 and -O2 (also with Python -O).
• A temporary production-helper mutant widening the ACTUAL mask from GENMASK(7, 4) to GENMASK(8, 4) passes the old test at both optimization levels, but the new test rejects it at both levels (0xeffffff0, expected active=true). The mutant was confined to a temporary directory and was not committed.
• tools/aurora-ci/check-commits.py --base c89018ed79c338c40eb67080b3005235060fedd6 --head d17068fc1f78fcde813d4169c05c1db37aa61fcf passes, with the sign-off present and checkpatch clean.

This adds a commit after your approval; the CPU checks do not establish hardware auto-wake behavior.

Written by Claude on @satchlj's behalf.

[chriskearney]

Update 2026-10-31 05:45Z: normal pull-request Kernel CI creation has resumed. The reopened, unchanged heads have actual normal runs: #301 d17068fc in 41170850065, attempt 2, and #302 d2c35b61 in 41170855244, attempt 2. The ordinary vouched-author workflow handled the initial approval; no approval policy was bypassed.

At that observation, both runs had nine successful completed jobs, including fresh KUnit (1,734 pass, 3 expected skips). Both package builds were still in progress. The packaged-kernel boot and final result were not yet available, so this is incomplete CI, not full acceptance. The actual run merge commits were bound to base 2dd4aab6 and the respective reviewed heads. The bounded read-only watch ended at 05:45Z; these external runs may finish later.

The separate m1n1 repository still returned the literal Actions-disabled HTTP 422 at 05:03:17Z. Kernel run creation does not establish m1n1 availability or qualify its PR.

Earlier diagnostic, preserved for chronology:

Update 2026-10-31 02:58Z: direct diagnostic starts against the existing integration bases returned HTTP 422: Actions has been disabled for this repository. This was observed for omacom/m1n1 at 02:52:34Z (base bc79acc4) and omacom/linux-aurora at 02:58:04Z (base 2dd4aab). Each request used its existing workflow_dispatch entry, once. No job was created and no PR code ran.

This establishes the current Actions-availability blocker for both repositories. It does not identify which repository/organization setting disabled it, who did it, or when. A maintainer with policy access has been asked to inspect and restore Actions while retaining the existing fork-approval and allowed-actions rules. Our current policy reads return403; no workflow or policy settings have been changed by us.

Earlier checks found matching event/branch filters, active workflow definitions and the author already vouched. The two ci:build label events at02:33:40/41Z were also recorded but produced no requested-build runs. These were separate review-build requests, not replacements for required normal CI. After Actions is restored, a fresh matching PR event is needed; these diagnostics provide no PR build/test qualification.

[chriskearney]

Re-reviewed d17068f against c89018e. Only tools/asahi/test-j613-dcp-power.py changes; production and the host-test registration are byte-identical, so the earlier provider-equivalence source result still applies without repeating that exhaustive run.

The exact test now crosses all 512 ACTUAL/TARGET/AUTO combinations with 27 unrelated-bit patterns (13,824 words), and passes at -O0 and -O2. The broad AUTO mask mutant that survived the old test is now rejected, as is the ACTUAL-only revert. The captured-state controls remain. Composition with #302 still needs the same registry conflict resolution preserving both tests; the new composed tree differs only in this test file.

Source approval renewed at this exact head. All earlier scope limits remain: no independent hardware auto-wake, packaged-default or GPU benchmark qualification; J615 and thermal/firmware gates unchanged; #302's newer-firmware effect depends on the separately unreviewed Extended-profile stack. There is still no observed exact-head Actions run or full kernel build. Normal composed CI/package checks are required before merge. The CI-start issue is separately recorded in comment 6537815090 and is not cleared by these host passes.

[satchlj]

Thanks @chriskearney. One more data point for linux-aurora: the repo hasn't started any Actions run for anyone since 2026-10-30 22:51:59Z (the last one is the merge-queue push for #300). #301/#302 and the #303–#307 drafts are simply the only new PRs since then. So it looks like the same thing as m1n1 (Actions has been disabled for this repository) rather than anything specific to these PRs or their author. For comparison, omacom/omarchy-pkgs last ran at 02:37Z, so it isn't org-wide.

Written by Claude on @satchlj's behalf.

[chriskearney]

Not for this RC at this time. We already have the 14.8.3 path working and tested on both M3 Air models (J613 and J615), and want to keep that validated firmware path stable.

I understand that these prerequisites do not themselves switch an installed machine's firmware. We are nevertheless deferring the additional 26.6.2 support work from RC unless there is a clear user-visible gain or compatibility requirement we are missing. Could you document any such benefit, particularly for users already working on 14.8.3?

Please hold both #301 and #302 from the merge queue for now. The source-review approvals stand; this is an RC scope decision. The now-green normal CI is acknowledged, but does not change that release decision.

[satchlj]

Thanks @chriskearney. We'll keep #301 and #302 out of the merge queue until you decide. Keeping the RC on the validated 14.8.3 path is a reasonable call, and so is including 26.6.2 support. Since most of the benefits only hold if 26.6.2 is in the RC, I'd ask you to weigh them before the RC:

• Switching later is a cost for users. If the direction is 26.6.2, every M3 Air user who installs the RC on 14.8.3 will have to change firmware later. Supporting 26.6.2 in the RC means fewer people go through that switch.
• 26.6.2 has a track record here. My J613 has run daily on 26.6.2 firmware for weeks (on our earlier kernel), and the official chain with these fixes reached native GPU and the internal display in yesterday's test boot. That's one boot so far, with more planned.
• GPU clock. In our earlier experiments J613's GPU on the 14.8.3 path ran its shader clock at about 3/4 of the requested speed (≈1001 MHz at the 1338 MHz top state), while the 26.6.2 path reaches the full 1338 MHz. That measurement predates your current 14.8.3 stack, so it may no longer apply. A like-for-like check would settle it: same glmark2/vkmark settings plus a GPU clock readout on a lab J613 on 14.8.3, and on rubra on 26.6.2. We can run our side in the next session.
• Newer Wi-Fi/Bluetooth firmware may carry security fixes. That's speculation; we haven't verified any specific fix.

Either way is reasonable. These PRs don't change the 14.8.3 path, so including them doesn't put the validated path at risk.

Written by Claude on @satchlj's behalf.

[chriskearney]

Thanks—the reported clock uplift from about 1001 to 1338 MHz is significant enough to investigate. If it is confirmed on the current stack and translates into application performance, that would be a real reason to prefer the improved path.

We had a major M3 Pro performance issue addressed by Eryk’s GPU power-vote/PMP bandwidth-reporting work (#238, carried in #253). The Air uses a different PMP path, so a related power/bandwidth issue is a useful hypothesis to check, rather than an established explanation. The Air’s current performance-state caps and thermal policy also need to be recorded so we can distinguish firmware benefits from configuration differences.

I checked the current #307 admission code: the 26.6.2 profile is J613-only, so it does not yet cover the 15-inch J615. Getting 15-inch support in is the single biggest addition that would help us. If this series covers both Air models and matched tests demonstrate the gain, normal packaged boot, regression coverage and stable thermal behavior on both, I would prefer that improved driver/firmware path.

Please prioritize J615 support and a comparison against the current 14.8.3 stack, with kernel/userspace versions, workload settings, measured clocks and performance/thermal limits recorded. Keep the RC merge hold in place while that coverage and evidence are reviewed; the source approvals stand.

[satchlj]

Thanks @chriskearney, that's helpful. Plan on our side:

• J615: we don't have a 15-inch Air, so we'll do what we can offline. Our earlier research found the 26.6.2 IPSW ships the same DCP, PMP and GPU firmware for J613 and J615, and the J615 ADT matches J613's in every node this path uses. We're preparing J615 support as small additional commits on the series, with the source of every board-specific value recorded, plus a test plan. Is there a J615 in the Mac lab that could run it? A matching J613 run on the lab side would also help.
• Comparison: we're writing an exact recipe for both stacks: kernel/m1n1/Mesa/userspace and firmware versions, fixed glmark2/vkmark and application workloads, live GPU clock readout, performance-state caps and thermal trip points, a 10-minute sustained run with temperatures and power draw. It includes a check for the PMP power-vote/bandwidth hypothesis (Fix M3 Pro GPU bandwidth and G15 submission overhead #238/drm/asahi: carry G15 submission fixes and T6030 PMP votes with host coverage #253). We can run the 26.6.2 side on rubra (J613); the 14.8.3 side would need a lab machine.

We'll post the recipe and the J615 test plan here when they're ready. The RC hold stays as you asked.

Written by Claude on @satchlj's behalf.

[satchlj]

@chriskearney, the two pieces you asked for:

• J615: draft drm/asahi: admit opted-in J615 on the shared 26.6.2 profile #310 lets the 15-inch Air onto the 26.6.2 profile behind the same exact opt-in m1n1 and DCP already use (chosen.asahi,j615-25g83-experimental = "1"). The 26.6.2 IPSW ships the same GPU/DCP/PMP firmware for both Airs, and the J615 ADT matches J613's in every node this path uses, so no J615-specific tables were needed. It is not qualified on hardware; we don't have a J615.
• Comparison recipe and J615 lab plan: https://gist.github.com/satchlj/fb5c04c6b379319fc5ca2c5da3678a8c (protocol, run.sh, collect.py, caps/thermal table, J615 test plan with safe return).

Known limits:

• The two stacks don't run with the same caps: 14.8.3 defaults to PSTATE_CAP=2 with the host thermal governor, while the extended path runs to state 8 under the native firmware controller. The first comparison will show shipped-default behaviour, not a firmware-only difference.
• There's no safe, driver-owned continuous clock sampler yet. The recipe records firmware-reported state on 14.8.3 and leaves the measured-clock part open, rather than substituting advertised MHz.
• On the PMP hypothesis: the Fix M3 Pro GPU bandwidth and G15 submission overhead #238/drm/asahi: carry G15 submission fixes and T6030 PMP votes with host coverage #253 PTD report is gated to T6030, so the Air gets no equivalent on either firmware. That's a missing code path, not evidence the Air needs the same report.

If a lab J615 (and a J613 on 14.8.3) can run this, we'll run the 26.6.2 side on rubra next session.

Written by Claude on @satchlj's behalf.