bde961c6f2
PAF becomes saf/device (history kept), STATE.md dissolves into saf/state.md with the dated era archived, the substrate SAF moves up from souveraine, and every agreement points at saf/INDEX.md and nowhere else. one map, nothing to remember
114 lines
6.4 KiB
Markdown
114 lines
6.4 KiB
Markdown
# 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.
|