[RyanTheTide]

What

On the J616s (T6040, M4 Pro) the ANE_SYS power domain sometimes comes back from s2idle with its PMGR register at 0x0b4f: target 0xf, actual 0x4 (clock-gated) and bit 11 set, which means its upstream (the SoC fabric) is not available yet. Every domain except T6000 GFX gets only a 100 us budget, so this logs

apple-pmgr-pwrstate ...@3c0: PS ane_sys: Failed to reach power state 0xf (requested 0xf, now: 0xb4f)

and genpd ignores the error on the resume path. The ANE firmware is then started on a sys domain that is still clock-gated.

T6000 GFX shows the same register pattern on noirq resume and already gets a separate bounded wait for bit 11 (e8643ee). This change gives T604x ANE_SYS the same wait: up to 10 ms for bit 11 to clear, then the usual 100 us for the actual state. A parent that never comes back still fails and logs. ANE_SYS is matched by compatible, offset and label, because 0x3c0 is also atc1_cio in another T604x PMGR block. No other domain changes.

One commit, drivers/pmdomain/apple/pmgr-pwrstate.c.

Why it matters

• Clean boot log: FLEET2 saw 2 of these lines in 18 J616s resume cycles on fleet20.
• ANE: in an 80-wake J616s run (t-5390) this line came right before 3 of the 10 natural H16 firmware startup stalls. linux#1066 now recovers those stalls with a restart (about 3 s per wake), but a stall that never starts is better than one that is recovered.

Tests

• KUnit pmgr-pwrstate (arm64, .kunitconfig.pmgr-pwrstate): 10/10.
• checkpatch --strict: 0/0/0. W=1 drivers/pmdomain/apple: 0 warnings (test kernels fleet22anex1, fleet23anex2).
• J616s hardware: pending (the J616s is a macOS render node until about 05:00). Plan: 40 s2idle wakes on test kernel fleet23anex2, counting ane_sys: Failed to reach, H16 startup stalls and restarts against the fleet23 numbers. Draft until then.

🤖 Generated with Claude Code

[RyanTheTide]

J616s run 11-08 06:31-06:42 (lane ANEX): test kernel 7.3.0-aurora-fleet23anex2 (fleet23 + this commit), 30 s2idle cycles with an ANE program loaded: 30 resumes ok, 0 ane_sys: Failed to reach power state lines, 0 failed or refused sleeps, and 1 natural H16 firmware startup stall that one restart (linux#1066) recovered. The fleet27 control had 25 s2idle cycles, 25 ok, 0 stalls and 0 ane_sys lines. This harness (systemd s2idle through the kit) did not reproduce the 0x0b4f line even without the fix; FLEET2 saw it in direct pm_test cycles. A stall still happens with the fix, so the parent wait is not the startup-stall root cause. It stays a draft until a direct pm_test A/B shows the line gone.

[RyanTheTide]

J616s A/B on 2026-11-09, 15 RTC s2idle wakes per arm (kit v13c suspend path):

Arm	Kernel	ane_sys power-state failures	Resume to node reopen
stock	fleet37	0/15	12-19 ms
with this change	integration c8a58d8 + this change	0/15	11-15 ms, plus one 3029 ms H16 startup stall that a restart recovered

The ane_sys: Failed to reach power state line did not reproduce on either kernel, so this proves nothing either way. The fleet20 rate was 2 in 18 wakes. This stays a draft until a longer run shows the line on stock.

🤖 Generated with Claude Code

[RyanTheTide]

The Neo (T8140) shows the same signature (0x2b4f: target 0xf, actual 0x4, bit 11). There, bit 11 turned out to be a latch, not a slow parent: it stayed set for 20 ms with every fabric parent on, it survived gating the domain (0x2b00), and only a PS reset pulse cleared it. #1255 adds that recovery for every domain that has no wait_parent, so it covers the T604x ANE_SYS as long as this PR is not merged. If this PR lands, ANE_SYS becomes a wait_parent domain and #1255 skips it. Suggest closing this in favour of #1255 unless a J616s run shows bit 11 clearing by itself within 10 ms.

🤖 Generated with Claude Code

[RyanTheTide]

Superseded by #1255 (a10defe, in integration/aurora): a latched bit 11 on power-on now gets a PS reset for every domain without wait_parent, which covers the T604x ANE_SYS; the sleep-time path is #1303.