SouveraineOS/saf/device/evidence/audio/HANDOFF-mic-unpin.md

Handoff — Pixel 3 mic: un-pin the microphone

Historical handoff. Current functional status and the remaining power debt live in ../../audio.md and ../../../docs/tasks/07-mic-wcd9340-slim-tx.md.

CORRECTED 2026-07-19 evening — read audio.md "THE BOOT RACE" first. The QRTR=y contamination theory below is disproven: all of today's dead-mic boots (every kernel, every config) lost a boot-time sysclk race; the working 262k boot and one untested bdf098937 boot won it. bdf098937 is clean and deployed; the un-pin test below is still valid but ONLY on a boot whose pinned baseline reads nonzero. Cold boot until baseline is nonzero, then run the test as written.

The one task

Fable got the mic working via a PA mic-hold that pins blueline_mic open from boot (rootfs-overlay/etc/pulse/default.pa.d/90-blueline-alsa.pa, the module-loopback into a null sink). The only job left: make the mic survive close/reopen so the always-on pin can be removed. Nothing else. Do not expand scope.

Known-good state (trust this, do not re-derive)

• Working-mic kernel: 323b29715 (branch mic-fix, gitea Fimeg/linux-blueline). MCLK root cause already fixed upstream of it (LN_BB_CLK3, commit 7c6559e0c). With the PA pin loaded, capture is real audio: ~262k/263k nonzero samples/3s, verified this morning.
• The un-pin attempt: bdf098937 = 323b29715 + one commit only ("slimbus: qcom-ngd: send CHAN_CTRL remove on stream disable"). Its parent IS the working kernel, so bdf098937 is exactly "working mic + un-pin, nothing else."

What bdf098937 does (already reviewed, wire format is correct)

• drivers/slimbus/qcom-ngd-ctrl.c: adds qcom_slim_ngd_disable_stream → sends CHAN_CTRL(REMOVE) + RECONFIG_NOW to the ADSP master on stream disable. Mainline had dropped all 0x40–0x5F reconfig messages, so the master kept the channel "active" after close and a same-map reopen no-op'd → zombie zeros. Wire format matches downstream slim-msm-ngd.c exactly: (SLIM_CH_REMOVE<<6)|(laddr&0x1f), TID, chan ids, mc=SLIM_USR_MC_CHAN_CTRL.
• sound/soc/codecs/wcd934x.c: swaps teardown order to disable before unprepare (unprepare frees stream->ports, which made disable a silent -EINVAL no-op).
• On-phone evidence it reached the wire: MICDBG CHAN_CTRL remove ... ret=0, GENERIC_ACK code 0x20. So the removal is sent and ACKed.

The actual open question

bdf098937 has never had a clean test. Every observation today was contaminated:

1. Tested with the PA pin still loaded → disable never fires (0 shutdowns in dmesg), so the new code path never ran.
2. Then it got built ON TOP of a QRTR/PD_MAPPER =y config change into fdb22e5 (see contamination below), and every "still zero" result was on that kernel, not on clean bdf098937.

So it is unknown whether the CHAN_CTRL-remove actually un-pins the mic. That is the thing to find out.

Contamination to be aware of (my mess — Opus, this session)

• Commit fdb22e5 on mic-fix flips CONFIG_QRTR=y + CONFIG_QCOM_PD_MAPPER=y (was =m/=m). This is a boot-time change stacked on top of the un-pin commit and it correlates with the mic going dead. Whether QRTR=y is causally breaking the mic or is a red herring is NOT established — but it must NOT be in the kernel used to test the un-pin. Ruled out as a probe-race: on fdb22e5, audio_pd came UP at 1.3s, codec armed capture at 13.5s (12s later, no race). 0x1fffffff = SERVREG_SERVICE_STATE_UP (I first misread it as down — it is UP).
• The repo config kernel/config-blueline.aarch64 currently has QRTR/PD_MAPPER =y (my commit f245323 in Fimeg/Pixel3Arch). For a clean un-pin test the build config must be QRTR=m/PD_MAPPER=m (the working-mic config).
• Phone is currently running the contaminated gfdb22e5; mic reads zero.
• ArchDev ~/build/pixel3arch-kernel was hand-abused with direct sed + makepkg (NOT the pipeline). Ignore that dir. config-blueline.aarch64 there was left at =y.

The correct next step (build ONE kernel, via the pipeline)

Build bdf098937 with the working-mic config (QRTR=m, PD_MAPPER=m), clean, and test the un-pin. Concretely:

1. Point the build at commit bdf098937 (its config, in Fimeg/Pixel3Arch, must be QRTR=m/PD_MAPPER=m — the pre-f245323 values).
2. Build through the real pipeline only: ~/Projects/Pixel3Arch/kernel on ArchDev, ./build.sh <branch-at-bdf098937> (see PAF/build.md — it fresh-clones from gitea and hard-asserts built hash == gitea tip; never hand-makepkg, never the ~/build side dir).
3. Deploy with scripts/deploy-kernel.sh (modules-first, refuses to bless a boot where uname -r != installed module tree — PAF/build.md doctrine).
4. Cold boot (true power-off, unplug — no warm reboot; warm reboots poison TZ/remoteproc on blueline).

The test that answers it

On the clean bdf098937 boot:

1. Confirm mic works pinned: parecord --device=blueline_mic → nonzero (baseline sanity; pin is loaded from boot).
2. pactl unload-module module-loopback (drop the pin → the source can now actually close).
3. parecord again, close it, parecord a second time on the SAME TX5 map.
4. Watch dmesg | grep MICDBG for shutdown + CHAN_CTRL remove ret=0 on the close, then a fresh DEF_ACT_CHAN on the reopen.
5. Success = the second/third reopen reads nonzero. That means CHAN_CTRL remove re-armed the path and the pin can be deleted from 90-blueline-alsa.pa.
6. If it still zeros: the un-pin theory needs more than channel-remove. Next thing to check is whether the port (not just the channel) needs explicit disconnect/reconnect — downstream slim-msm-ngd.c handles DISCONNECT_PORT (mainline does it in slim_stream_unprepare via slim_disconnect_port); verify it actually fires on close in dmesg, and whether a port re-CONNECT is needed on reopen. Downstream source is local at ~/Projects/pixel3-downstream-audio/drivers/slimbus/slim-msm-ngd.c (git: git show HEAD:drivers/slimbus/slim-msm-ngd.c).

Do NOT

• Do not roll back / chase old commits beyond bdf098937.
• Do not remove QRTR/PD_MAPPER as the permanent config — pd-mapper being built-in is wanted; it just must not be in the un-pin test kernel.
• Do not hand-sed configs on ArchDev or hand-makepkg. One change, in the repo, pushed, built by build.sh.
• Do not tear down the working pin except as step 2 of the test above.