Fimeg/SouveraineOS
Watch
1
0
Fork
You've already forked SouveraineOS
 0
Code Releases Activity
SouveraineOS/saf/device/audio.md
Fimeg bde961c6f2 saf: one spine — device, state, and work under the index 
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
2026-08-18 09:47:30 -04:00

836 lines
51 KiB
Markdown
Raw Blame History

# Audio — WCD9340 / SLIMbus
## Current — 2026-08-07
This is a working phone audio stack, not an active microphone bring-up.
- **Runtime:** PipeWire + WirePlumber + pipewire-pulse + pipewire-alsa. Native
PulseAudio and the ABI-provider shims are historical experiments, not the
running authority.
- **HiFi:** both CS35L36 speakers play; the WCD9340 microphone captures clean
mono audio through DMIC4 → DEC5/TX5. Casey uses it regularly for STT.
- **Calls:** the `Voice Call` UCM profile, `souveraine-callaudio`,
`souveraine-q6voiced`, and `souveraine-callaudiod` carry real two-way calls
and the earpiece/speaker path.
- **Persistence:** WirePlumber restores volumes and the selected profile. Do
not add another volume writer; role policy remains TASK-39.
- **One hardware debt remains:** the kernel permanently holds codec sysclk and
MICB2 from probe. Audio works, but the hold costs idle power and blocks a
clean suspend story. TASK-07 owns removing it.
The July **“UN-PIN TEST PASSED”** below removed the userspace always-open mic
pin. It did **not** remove kernel commit `cd7758eae`'s sysclk + MICB2 hold; that
similar noun is the likely source of the remembered “we resolved it.”
The implementation lives in Pixel3Arch under `pkgs/souveraine-ucm-blueline`,
`pkgs/souveraine-wireplumber-blueline` (which packages the canonical
WirePlumber policy from `rootfs-overlay/`), `pkgs/blueline-callaudio` (package
name `souveraine-callaudio`), `pkgs/souveraine-callaudiod`, and
`pkgs/q6voiced` (package name `souveraine-q6voiced`).
Everything below is the evidence ledger. Headings such as “still open” describe
the date beneath them unless the current block above repeats the defect.
## UCM PROFILE GONE AT BOOT — 2026-08-16, fixed same day
Boot-time music died after kernel `7.1.1.r162.g457a667bd3eb` (installed
2026-08-13, first boot 08-16 00:46): the card came up with only `off` and
`pro-audio`, no UCM profiles, so no HiFi sink existed at boot. In-session
audio (calls, STT mic) kept working — the regression only hit the fresh-boot
state, which is why it surfaced as “music at boot”.
Measured chain, all on-device:
- **Kernel made routed capture strictly mono 48k.** The wcd934x
recorder-state work in r162 (`b30e849be` “program all DMIC interface pads”,
`9610ef9cf` “replay complete blueline recorder state”) rejects stereo
capture hw_params on the routed MultiMedia2 (`CHANNELS: [1 4]` advertised,
but `arecord -c 2` → -EINVAL, `-c 1` → fine).
- **ACP probes with declared UCM values.** The Mic devices declared no
`CaptureChannels`/`CaptureRate`, so ACP assumed stereo at the FE-default
rate → capture probe failed -EINVAL → every profile “not supported” → ACP
fell back to `pro-audio` (priority 1) at boot.
- **Secondary lock, not the cause:** `90-blueline.conf` sets
`session.suspend-timeout-seconds = 0` on `~alsa_output.*`, so the pro-audio
sink never released hw:0,0; later probes died “Device or resource busy”.
The persisted `default-profile` state (wireplumber saves the selected
profile, by design) then re-pinned `pro-audio` each boot.
- **Fix:** declared `CaptureChannels 1` + `CaptureRate 48000` in both Mic
devices (HiFi + VoiceCall). ACP probe now succeeds; all three UCM profiles
form; card activates HiFi at boot. Tone verified audible on glass; mic
capture nonzero through the UCM source. Shipped as
`souveraine-ucm-blueline 0.1.0-2` (commit `9f0f103`, CI run 1696);
rootfs-overlay UCM copies kept identical to the package.
- **Not shipped, known hardening:** scope the never-suspend output rule to
`~alsa_output.platform-sound.*__sink` (the UCM sinks) so a stray pro-audio
fallback can never hold hw:0,0 forever.
Probe mechanics learned (canonical, 2026-08-16):
- `spa-acp-tool -v -v hw:0` is the ACP probe; “Probing profile X” with no
failure lines after it = supported. The trailing “unknown command hw:0” is
a harmless arg-parsing quirk.
- `alsaucm -c hw:0 set _verb HiFi` is the real-card UCM branch; it runs the
verb EnableSequence (and enables devices — TX5 mapping included). `-c G3`
and `-c "Google Pixel 3"` hit the *no-hw* branch (conf.virt.d / legacy
paths) and fail ENOENT even when UCM is healthy — red herrings.
- `alsaucm list profiles` / `get _verbs` fail with ENOENT quirks on this
box; they are not valid probes.
- `cat /proc/asound/card0/pcm*p/sub0/status` shows `owner_pid` — the way to
find who holds a PCM.
- Raw `arecord -D hw:0,1` only works while the verb routes are applied;
`spa-acp-tool` runs DisableSequence on exit and tears them. Re-apply the
verb before raw capture tests.
## PIPEWIRE RESTORED — 2026-07-19 late evening
The PA-native arrangement is retired. Live state, all verified on-device:
- **Stack:** pipewire 1.6.8 + wireplumber 0.5.15 + pipewire-pulse +
pipewire-alsa. The shims (`pipewire-abi-provider`, `pulse-native-provider`)
and the patched `pulseaudio-q6` are removed (rollback pkg kept at
`~/build/pulseaudio-q6-r3/`; `/etc/pulse` backed up as
`/etc/pulse.bak-20260719`). The `enable-pipewire` gate drop-ins were
deleted — PipeWire is unconditional now.
- **UCM discovery works under ACP/wireplumber.** HiFi verb → Speaker sink +
Mic source appear named from the UCM comments. The old `alsaucm -c G3`
`-2` failure is an id-vs-longname CLI quirk; `-c "Google Pixel 3"` parses
both verbs fine. Real clients are unaffected.
- **Playback:** `51-blueline-audio-s16.conf` (S16LE + disable-mmap +
generous periods, recovered verbatim from `8920c3c`) reinstated; chime
confirmed audible on glass.
- **Capture:** mic source pinned mono S16LE 48k, suspend disabled,
period 4800 / headroom 9600 (`90-blueline.conf`). Nonzero on every test
capture.
- **UN-PIN TEST PASSED.** With the kernel sysclk hold (`cd7758eae`) and no
loopback hold, two consecutive same-map reopens both captured nonzero
(451k/470k nonzero samples). The userspace mic pin is DELETED — kernel
hold alone is sufficient. Cold-boot confirmation pending.
- **New kernel bug found and fixed:** any xrun → userspace
`snd_pcm_prepare()` re-enters wcd934x prepare without shutdown →
`slim_stream_prepare` -EINVAL "Stream already Prepared" retried ~50/s
forever (PipeWire recover loop starved the whole graph). Fix
`f56b1ae08` on `mic-race-fix`: per-dai `prepared` flag, re-prepare
no-ops, stream stays armed (alternation-law friendly). Wireplumber
headroom masks the common case until the kernel is installed.
- **VoiceCall.conf `hw:0,5` → `hw:0,2`** fixed on-device + repo.
- **Voice-call discovery:** VoiceMMode1 (`hw:0,2`) open fails -EINVAL until
the voice BE routes (`SLIMBUS_0_RX Voice Mixer VoiceMMode1`,
`VoiceMMode1 Capture Mixer SLIMBUS_0_TX`) are applied — DPCM
no-backend rejection. With routes applied the PCM opens. This is why
q6voiced logged "Failed to open tx/rx: Invalid argument". ~~Because the
PCM is unprobeable, ACP can never synthesize a VoiceCall profile, so
callaudiod's profile-switching path is structurally dead on this card.~~
**Wrong — see 2026-07-29.** ACP never probes `hw:0,2`; it probes the PCMs
the verb *declares*, and the profile was lost for two reasons of our own
making. Shipped `blueline-callaudio-hook` (system service): MM `CallAdded`
→ UCM voice verb, last call terminating → HiFi verb restore. q6voiced then
opens an already-routed PCM.
## PHONE CALLS WORK — TWO-WAY AUDIO ON A REAL BEARER — 2026-07-29
Incoming call, answered, audio both directions, confirmed by ear at both ends.
Five defects had to fall, every one of them ours:
- **Verb named `VoiceCall`.** alsa-lib's `SND_USE_CASE_VERB_VOICECALL` is
`"Voice Call"`, with the space, and callaudiod accepts only a profile
carrying that prefix (`cad-pulse.c:508`). Renamed.
- **The voice verb gave MultiMedia1 no backend.** HiFi routes it through
`QUAT_TDM_RX_0`; the voice verb routed nothing, so opening `hw:0,0` under
the verb returned -EINVAL and ACP dropped the profile — *"Profile 'Voice
Call' mapping 'Voice Call: Speaker: sink': output PCM open failed"*,
`spa-acp-tool -v -v`. That, not an unprobeable `hw:0,2`, is why no voice
profile ever appeared. The card carries one now.
- **Downlink went to `SLIMBUS_0_RX`.** blueline's earpiece and loudspeaker are
both CS35L36 amps on `QUAT_TDM_RX_0`; the WCD9340 is the uplink and the
headset jack. Voice sent to the codec reached nothing — audible as a call
the far end heard perfectly while this end heard silence.
- **A front-end takes exactly one backend.** These mixers are *not* additive:
enabling a second silently clears the first, measured in both directions.
Setting `QUAT` and `SLIMBUS` together is not belt-and-braces, it is a no-op.
- **q6voiced latches a failed open.** tinyalsa's `pcm_open()` returns a
non-NULL handle on failure and `q6voiced_open()` guards on `if (v->tx)`, so
one lost race silences the whole call. Reachable on any outgoing call:
`mm_state_is_active()` counts DIALING, emitted in the same instant as
`CallAdded`. Incoming calls are safe only by accident — RINGING_IN is not
counted active, so their open lands well after the routes. Patched in
`souveraine-q6voiced` to release and retry.
Two further findings:
- **The mic died after every call**, not just occasionally. `alsaucm` holds its
UCM context in-process, so a one-shot `set _verb HiFi` has no previous verb
to dismantle and never runs its `DisableSequence`. TX5 and TX7 both stayed
mapped into `AIF1_CAP`, SLIM_0_TX carried two channels into a mono front-end,
and capture read exact zeros. The hook now unmaps the outgoing leg explicitly.
- **callaudiod cannot own earpiece/speaker on this card.** It switches a sink
*port* (`cad-pulse.c:961`) and needs both port types on one sink, but ACP
models UCM devices as one profile per combination — `Voice Call (Earpiece,
Mic)` and `Voice Call (Mic, Speaker)`. `ConflictingDevices` does not change
it. enchilada sidesteps this by giving each transducer its own PCM; blueline
has both amps behind one. The toggle is therefore
`blueline-callaudio-hook speaker on|off`, writing the amps directly.
## ROOT CAUSE FOUND AND FIXED — MICS CAPTURE REAL AUDIO — 2026-07-19
**The wall was the codec master clock.** Mainline DT fed the WCD9340's `extclk`
from `RPMH_LN_BB_CLK2` (inherited from the reference-board dtsi). On blueline,
Android's own DT gives **LN_BB_CLK2 to the Pixel Visual Core (`mnh-sm`)** and
feeds the codec from **`clock_rpmh` index 4 = LN_BB_CLK3** (verified by
decompiling the phone's `dtbo_b`; `audio_ext_clk_lnbb` → `<&clock_rpmh 0x04>`).
The RPMh vote on the wrong buffer succeeds, so nothing errors — the codec just
never receives 19.2 MHz. That single fault explained the entire residue:
- eFuse sensing timed out every boot (`-110`, `status=0x0`) — needs MCLK, no
ports involved. After the fix: `eFuse sense complete: status=0x01 out14=0xda
out15=0x01` — first time ever on mainline.
- Analog AND digital capture read zeros (whole audio core unclocked) while
every SLIM control write ACKed (SLIMbus clock is separate).
- IRQ 213 (codec SLIM data line) never fired in the machine's life; after the
fix it fires on every capture.
- MBHC read garbage impedance at probe.
Fix: `&wcd9340 { clocks = <&rpmhcc RPMH_LN_BB_CLK3>; }` in
`sdm845-google-common.dtsi` (committed in the kernel tree). Deployed initially
as a verified one-byte DTB patch (`/boot/dtbs/sdm845-google-blueline.dtb`,
backup `.lnbb2-orig` beside it; kexec chain reads the DTB from `/boot`, NOT
from the boot_a image — see below).
**Live capture results after the fix (kernel `g8cbfbb939327`, same boot):**
- AMIC1 → ADC1 → DEC0 → TX0: 121,724 / 144,000 nonzero samples
- DMIC0 → DEC7 → TX7 (`hw:0,1`): 94,198 nonzero
- DMIC4 → DEC5 → TX5 (Android triple-mic route): 81,545 nonzero
- DMIC3 → DEC6 → TX6 (Android triple-mic route): 92,216 nonzero
- DMIC4 → DEC7 → TX7 (Android handset-mic route): 124,050 nonzero
All three physical mics (DMIC0/3/4 per Android's `triple-mic` path) and the
analog path produce real ambient audio through plain ALSA `hw:0,1` —
**no HAL, no ADM usecase, no ACDB OEM tree in the loop**. This falsifies the
"ADM usecase routing is required for samples to flow" hypothesis from the
2026-07-19 live-reconciliation doc, and retroactively confirms every "codec
registers are bit-perfect but silent" audit: the registers were right; the
silicon was unclocked.
### Boot chain discovery (why kernel deploys "never landed")
`boot_a` holds pocketboot (LinuxBoot, a 7.2.0-rc1 first-stage kernel). It
kexecs `/boot/vmlinuz-blueline` + `/boot/dtbs/sdm845-google-blueline.dtb` per
`/boot/extlinux/extlinux.conf` on Arch_root (`linux,booted-from-kexec` in the
live chosen node). Flashing boot_a via fastboot does NOT change the running
kernel/DTB — install to `/boot` on the rootfs instead.
### Then-open capture intermittency — superseded later on 2026-07-19
- Ordering effect observed on the first post-fix boot: DMIC3/4 through
MUX6/MUX7 read zero until the DEC5/DEC6 (Android-native) routes ran once;
after that, the previously-dead MUX7+DMIC4 handset route worked. Some
first-use state sticks. Full codec+IFD regmap snapshots of the known-good
state saved on-phone (`/tmp/codec-good-state.txt`, `/tmp/ifd-good-state.txt`
— copy off before they evaporate; /tmp is tmpfs).
- The last test of the session (speaker-tone loopback) read all-zero again
right after a string of successes — cause unestablished. Per the
live-reconciliation doc's warning, record airplane/radio/mode state before
interpreting ANY zero capture from now on.
- Android runtime parity notes for the diff: Android recording state has
`0xd25 = 0x11` (ADC MUX3/7 mode reg) where ours reads 0x00 even while
working; pads `0x8015-0x8018 = 0x00`, `0x8019/1a = 0x0a` — identical to what
our kernel programs (my in-session debugfs pad pokes don't persist).
- Regmap-cache caveat from the reconciliation doc applies to OUR debugfs reads
of IFD/PGD registers too: prefer live-read paths when auditing those.
### THE ALTERNATION LAW — exact zombie mechanism (2026-07-19, evening)
Every capture result from all three boots today reduces to ONE deterministic
rule: **a SLIM TX capture produces samples only when its channel map differs
from the previous capture session's map. Re-opening with the identical map
always reads zeros.** Verified live: TX5→TX5 = work,zero; TX5→TX6→TX5 =
work,work,work; boot-first TX7 always zero (ch135 is pre-touched by ADSP
boot/cal state, so the first TX7 session counts as a same-map reopen).
Everything earlier read as input-specific (DMIC3/4 dead), power-related
(PA holding sysclk), or "priming" was test-order artifact of this law.
- Codec side is fully correct per-session (DEF_ACT_CHAN wbuf identical
between dead and working sessions except TID; teardown calls
slim_stream_unprepare which sends DEACTIVATE/REMOVE/RECONFIGURE per
drivers/slimbus/stream.c).
- Clock gates during a zombie capture are bit-identical to Android's working
recording (0x711=0x91 0xd41=0x01 0xd42=0x0d).
- Conclusion: the ADSP's SLIM-master/AFE side treats an identical re-DEFINE
as a no-op and never re-arms the data path. Android never hits this because
its HAL/ADM re-arms per session (the reconciliation doc's ADM hypothesis,
refined: not "ADM required for routing" but "ADM masks the stale-restart").
- NEXT INSTRUMENTATION: log outgoing MCs in qcom_slim_ngd xfer path and
diff same-map vs changed-map session teardown/setup on the wire; then
candidate kernel fix = force a map perturbation or explicit port
disconnect+reconnect on every SLIM capture start.
- Userspace mitigation shipped meanwhile (see 90-blueline-alsa.pa): a
null-sink loopback holds blueline_mic open from PA start — the boot-time
open is on virgin TX5 (works), and a held-open source never re-opens, so
the law is never violated. VALIDATED on true cold boot 2026-07-19 12:09:
blueline_mic RUNNING at boot, 262k/263k nonzero samples first client,
two back-to-back client sessions both live (peaks 5256/5590/26044).
Costs continuous capture power (remove once the kernel fix lands).
### THE BOOT RACE — pinned boot capture is a coin flip; kernel + config were red herrings (2026-07-19 evening)
Journal survey of ALL 9 boots of 2026-07-19 (`journalctl -b -8 .. -b 0`,
MICDBG sysclk lines at the pin's boot-time capture open):
| boots | kernel | at pin open | MICB2 | outcome |
|---|---|---|---|---|
| -7 | g323b297 | `users=2 skip` (joined a live hold) | 0x50 | 262k WORKING |
| -3 | gbdf098937 | `users=2 skip` | 0x50 | never tested (!) |
| -8 | g323b297 | `users=1 full bring-up` after `users=0 HW POWER-OFF` | 0x10 | zero |
| -6 -5 -4, 0 | gbdf098937 | same losing pattern | 0x10 | zero |
| -2 -1 | gfdb22e5 | same losing pattern | 0x10 | zero |
An early boot-time actor grabs codec sysclk ~3s after boot, holds ~3s, and has
MICB2's 0x40 bit up while it holds. If PA's pin lands INSIDE that window the
capture joins as user 2 and samples flow; if it lands after the release (codec
did a HW POWER-OFF), capture does its own full bring-up and reads zero on every
route for the rest of the boot — the same persistent zombie the PA-stop
experiment produced. Same kernel both wins and loses (g323b297: won -7, lost
-8; gbdf098937: won -3, lost four). Therefore:
- **QRTR=y (`fdb22e5`/`f245323`) is exonerated.** Every "dead on fdb22e5"
observation was a lost race, sampled. Config stays QRTR=m / PD_MAPPER=m
(Kconfig forces PD_MAPPER ≤ QRTR anyway); it is orthogonal to the mic.
- **The CHAN_CTRL-remove commit (`bdf098937`) is exonerated for "dead at
boot"** — its code path is open-inert (only adds `disable_stream`, verified
by diff) and it won the race on boot -3.
- **The un-pin question is STILL unanswered.** It needs a race-winning boot:
pinned baseline nonzero, `pactl unload-module` the loopback, then same-map
reopen; nonzero reopen = pin can be deleted.
- The early holder is unidentified; MBHC headset-detect is the prime suspect
(boot-time codec user, raises MICB2 for impedance sensing). MICB2
0x50-vs-0x10 tracks outcome 8/8 but is NOT yet proven causal — it may just
fingerprint the hold. Verify before building on it: read Android's ANA_MICB2
during a working slot-B recording, and/or set the 0x40 bit via debugfs during
a fresh lost-race boot's capture.
- Kernel fix direction (pick after causality check): wire the DMIC supply
(micbias) into the capture DAPM path, or hold sysclk from probe until first
capture so the boot window cannot close early.
### Afternoon findings — zombie state + wedge reproduction (2026-07-19)
- Cold-boot experiment (radios all on, recorded): first `arecord` after boot
opened ONLY the FE — zero kernel-side codec/BE activity, zeros. Second and
third captures (any route) worked. The morning "DEC5 unlocks MUX7" story is
partly this: two distinct zero-classes exist — (a) BE-never-opened,
(b) BE-open-but-silent.
- Stopping PulseAudio (releasing the card → last sysclk user drops →
`wcd934x_disable_ana_bias_and_syclk` powers the codec down) put capture into
a persistent all-zero state on EVERY route, and restarting PA did not
recover it. Mixer state is bit-identical PA-up vs PA-down (diff empty), so
it is a power-lifecycle effect, not mixer state.
- In the zombie state, live volatile reads DURING capture show the analog
domain healthy: `ANA_BIAS=0x80 BUCK=0x07 MICB4=0x90`. The bias/buck theory
is dead. Codec-internal clock gates (0xd41/0xd42) were not yet live-readable
— instrumented build `323b29715` makes them volatile and logs
enable/disable/sido lifecycle + per-capture clock-gate reads.
- Manually zeroing `CLK_SYS_MCLK_PRG` (0x711) via debugfs wedged the SLIM bus
into the historical `-110` NACK loop (`Failed to read IRQ status: -110`,
`Error Interrupt 0x82000000`, 1 Hz). One historical "SLIM wedge" class is
therefore reproducible as pure codec-clock-state loss — consistent with the
2026-07-19 warning that not every wedge was a bus/driver fault. Phone needs
a cold boot after this (self-inflicted, cause exactly known).
- Upstream comparison: `enable_ana_bias_and_sysclk`/`disable` and the
sido-cache skip are upstream-inherited structure, not our divergence; our
only body change is the Android-parity buck sequence (captures work with
it). No structural smoking gun found by code audit — hence instrumentation.
## SLIM NACK loop confirmed boot-invariant on a real cold boot — 2026-07-15
- Fixed three misidentified raw-hex register writes in
`wcd934x_apply_blueline_android_tx7_capture_setup()` (kernel `5199244ee0ee`):
`0x0b07-0x0b3f` were RX playback compander `CTL6` registers (not TX
per-path enables), `0x0c96` is `WCD934X_SWR_AHB_BRIDGE_ACCESS_STATUS` (a
status register, not a TX enable — writing it was the suspected cause of a
SLIM wedge seen on the prior build `9610ef9cf45a`), and `0x0d1e`/`0x0d25`
are `ADC_MUX0_CFG1`/`ADC_MUX3_CFG1` (TX0/TX3, not TX7/TX8 as the old
comment claimed). Verified against downstream
`techpack/include/asoc/wcd934x_registers.h`. This fix did NOT resolve the
SLIM wedge — see below.
- The recurring error is a genuine **NACK**, not a bus hang:
`qcom,slim-ngd-ctrl: Error Interrupt received 0x82000000` decodes to
`NGD_INT_TX_MSG_SENT (BIT 31) | NGD_INT_TX_NACKED_2 (BIT 25)` — the
message transmitted and the target actively refused it. The target is
`LA:0xcf` (the WCD934x codec's assigned logical address, confirmed not
`SLIM_LA_MGR`/`0xff`), message code `0x60` =
`SLIM_MSG_MC_REQUEST_VALUE`. The read is `regmap-irq`'s generic
`regmap_irq_thread()` polling the codec's IRQ status registers
(`drivers/base/regmap/regmap-irq.c`) — the codec's IRQ line is
`IRQF_TRIGGER_HIGH` (level), so a failed status read never clears it and
it refires every ~1s, forever, from ~1-2min post-boot onward.
- Tested with a **user-operated true power-off (`shutdown -h now`, not
`fastboot reboot`) followed by manual power-on**, specifically to rule
out the in-place-ADSP-restart degradation `b0b813f` warned about. Result:
the NACK loop reproduces identically on this real cold boot (confirmed
climbing at 110s uptime, same `MC:0x60,LA:0xcf` signature). **This is not
a warm-reboot or ADSP-restart artifact** — it is boot-invariant, matching
the entry below from earlier the same day.
- `blueline-hexagonrpcd-adsp.service` (`b0b813f`, still uncommitted to
gitea as of this entry) attaches cleanly on this same cold boot — no
fluence/ECNS/AVS module errors, only the unrelated `lowi_lp.conf` miss.
So the ADSP audio-PD HexagonFS gap is fixed and not the current blocker;
capture still fails at the ALSA `hw_params` layer (`arecord` "Unable to
install hw params") before the ADSP module question is even reachable,
because the SLIM NACK loop blocks it upstream.
- **Current standing blocker, plainly:** the SLIM NACK loop on `LA:0xcf`.
Not yet root-caused. Two real, separate bugs were found and fixed
tonight (the register-write bug above, and the ADSP HexagonFS gap in
`b0b813f`); this is a third, still-open one.
## Cold-boot SLIM-NGD correction — 2026-07-14
- A user-operated full power-off while unplugged, followed by power-on, still
logs `qcom,slim-ngd-ctrl ... QMI wait timeout` at 12:29:52, immediately
after ADSP boot/WCD934x probe, followed by repeated `SLIM SAT: Rcvd master
capability`. This happened before any ALSA/Pulse microphone client opened.
- Therefore the timeout/capability loop is **not merely a warm-reboot or
long-uptime artifact**. ADSP, CDSP, SLPI, and MSS all reach `running`, so
the fault is specifically in the ADSP↔NGD SLIM initialization exchange and
is now the primary boot-invariant microphone lead. Do not restart ADSP or
NGD while investigating; preserve this state for tracing.
- The adjacent WCD MBHC threshold/impedance messages concern headset/accessory
detection (including the available USB-to-mic adapter), not the target
internal DMIC4 → DEC7 → TX7 capture path.
## Q6 VoiceMMode1 call path — staged 2026-07-14
- This is deliberately separate from the still-silent raw `MultiMedia1/2`
capture path. Android proves the board microphone works; normal PCM remains
an ADM/calibration problem, while modem calls use the hostless Q6Voice path.
- The missing board wiring was real: `sdm845.dtsi` left Q6 MVM/CVS/CVP
disabled and blueline had no `VoiceMMode1` DAI/card link. Kernel commit
`551d3bb1b` enables those services and instantiates the link on the tested
Type-C baseline. Its matching module tree is installed on the phone at
`7.1.1-sdm845-g551d3bb1bd35`; its boot image is staged locally.
- The preserved prior device package, found at
`archive/pmos-20260709/pmaports/device/testing/device-google-blueline/`,
is the authoritative board data: `VoiceMMode1` enumerates as **`hw:0,5`**,
not the raw MultiMedia devices. Its exact `VoiceCall.conf` routing
(`SLIMBUS_0_RX Voice Mixer VoiceMMode1`, `VoiceMMode1 Capture Mixer
SLIMBUS_0_TX`, DMIC4→DEC7→TX7) is installed in the Arch UCM overlay.
- `q6voiced-blueline` was built and installed natively, with that exact PCM-5
configuration. Its system unit is deliberately **disabled until the new
kernel cold-boot confirms `00-05: VoiceMMode1`**; enabling it on the old
kernel would create meaningless restart noise. First test must be a clean
cold boot and an actual ModemManager call *before any HiFi/raw-capture
experiment*, because the historical second call failure was SLIMBUS RX
already claimed by earlier HiFi activity.
## Live state — 2026-07-12 evening (mic)
**Live Android Recorder ground truth — 2026-07-14:** On the rooted Lineage
slot-B reference system (`4.9.337-gb929452c5c49`), an ordinary
`org.lineageos.recorder` recording was observed live, not inferred from XML.
It opens **MultiMedia1 / PCM device 0** (not MultiMedia2): its userspace input
is mono S16_LE at 8 kHz, while the active backend is
`SLIMBUS_0_TX`, mono S16_LE at 48 kHz. The downstream HAL enables
`DMIC4 -> DEC7 -> TX7`; `SLIM_0_TX Channels=One`; and its active capture
app-type control is `[69938, 4, 48000, 3]`: downstream's documented field
order makes that `app_type=69938` (the Qualcomm default TX-path app type),
`acdb_dev_id=4`, `sample_rate=48000`, `backend_id=3`. The capture track was active and
non-silent in AudioFlinger. Crucially, Android's dedicated WCD SLIM-interface
debug dump during that recording read `0x032=0x80`, `0x057=0x05`,
`0x097=0x21`, and `0x11c=0x80`. (`tavil-slim-pgd` regmap is codec register
space, not this interface-device space.) Every earlier Arch microphone
negative test targeted `hw:0,1` / MultiMedia2 at 48 kHz. The exact
**MultiMedia1 `hw:0,0` 8-kHz FE / 48-kHz SLIMBUS backend** retest then ran on
Arch with TX7/DMIC4 and the active speaker RX route preserved: its 8-second
raw payload was 128,000 bytes / **zero non-zero samples**. (An earlier
apparent 19-sample result was immediately identified as `arecord`'s 44-byte
WAV header and corrected with `-t raw`.) This closes the FE/rate mismatch as a
microphone fix. The Android HAL's ADM identity and ACDB path is now the
leading differential: it programs this FE's app type, topology, and device
calibration, whereas mainline q6routing passes zeros.
**DEF_ACT_CHAN client-field test — 2026-07-13:** The Android downstream NGD
driver encodes the first `DEF_ACT_CHAN` payload byte as
`(data_fmt << 5) | (laddr & 0x1f)`; mainline had sent the full WCD9340 logical
address (`0xcf`) and consequently put its high bits into the data-format field.
The one-line correction was built on the current Type-C/G56 test base as
`3ceab71eded0`, its matching module tree was installed before flashing, and
the resulting `7.1.1-sdm845-g3ceab71eded0` boot was verified on glass. A
controlled single-direction `DMIC4 → DEC7 → TX7 → MultiMedia2` 48 kHz mono
capture (TX6 disabled) produced `384000` bytes / `192000` samples, with **0
non-zero bytes** and signed-16 range `0..0`. ALSA state restored (only the
known read-only HPH controls complained); no new SLIM/Q6/NGD timeout or audio
error appeared. This fix is a valid protocol correction and must remain, but
it is **not sufficient to make blueline microphone capture work**.
**Android DMIC-pad + analog split test — 2026-07-13:** Android's WCD9340
initial register table writes `DMIC3_CLK_PINCFG`/`DMIC3_DATA_PINCFG`
(`0x8019`/`0x801a`) to `0x0a`; mainline defined but never programmed those
registers. That exact pair was added to WCD934x component initialization,
built as `959f0d5e6`, and booted as
`7.1.1-sdm845-g959f0d5e65fc`. The normal Android handset route
`DMIC4 -> DEC7 -> TX7 -> SLIMBUS_0_TX -> MultiMedia2` remained exactly zero
(384000 bytes / 192000 signed-16 samples / zero non-zero bytes), without a
capture-time SLIM, Q6, or ADSP error. A separate reversible replay of
Android's analog fallback `AMIC1 -> ADC1 -> DEC6 -> TX6` also produced the
same exact zero stream. Thus neither the DMIC3 pad configuration nor a
bottom-DMIC/flex-only fault can explain the failure: the common remaining
boundary is codec TX channel activation and/or the ADM/ADSP capture path.
The only ALSA restore errors were the known read-only HPH impedance/type
controls.
**ADM/calibration lead — 2026-07-13 (refined 2026-07-14):** Mainline `q6routing_stream_open()`
unconditionally passes `NULL_COPP_TOPOLOGY` and app/acdb values of zero to
`q6adm_open()`. Pixel Android's `msm-pcm-routing-v2.c` starts with that
fallback but looks up topology, app type, and ACDB device ID by FE/BE/session
from audio-calibration tables before opening ADM. Do not replace the topology
with a guessed constant: the live Android `MultiMedia1 + SLIMBUS_0_TX`
recorder has now identified `app_type=69938`, `acdb_dev_id=4`,
`sample_rate=48000` (and backend ID 3). The exact ADM topology was decoded
from the extracted board-matched ACDB on 2026-07-14; see the next entry.
**ADM identity-only test — 2026-07-14 (negative):** Kernel
`7.1.1-sdm845-g3b9cf346af3a` passed Android's observed `app_type=69938` and
`acdb_dev_id=4` only for live `SLIMBUS_0_TX` capture, leaving the topology
`NULL` rather than inventing one. The matching modules were installed before
the pmOS-chain `boot_a` image was flashed; the running kernel and modules
matched. A controlled `MultiMedia1` / `hw:0,0`, mono S16_LE 8 kHz raw capture
with the Android-equivalent `DMIC4 -> DEC7 -> TX7` route yielded 128,000 bytes
with **zero non-zero samples**. ALSA state was restored (only the known
read-only HPH controls refused writes). This eliminates the two ADM identity
numbers alone as a microphone fix. The remaining Android differential is the
calibration-selected ADM topology and/or downstream codec-side programming.
**Board ACDB topology decoded — 2026-07-14:** The local Lineage vendor blob
`blobs/los-vendor/etc/acdbdata/OEM/sdm845-tavil-b1-snd-card/Handset_cal.acdb`
is not merely a future reference: `acdb-ldp` decodes its `HANDSET_MIC` device
4 configuration map as `69938 -> 0x00010315` (at 48 kHz). Downstream's
`apr_audio-v2.h` names `0x00010315` as
`ADM_CMD_COPP_OPENOPOLOGY_ID_MIC_MONO_AUDIO_COPP`; it is the specific Android
mono-microphone COPP, rather than the mainline null passthrough
`0x00010312` or a guessed default. This explains why the identity-only test
was necessarily incomplete. The present 7.1.1 tree also contains q6core's
optional ACDB topology-registration code, but blueline's q6core DT node has
no `qcom,acdb-name` and no `Global_cal.acdb` is installed as firmware, so that
path is currently dormant.
**ADM topology + AudProc test — 2026-07-14 (negative):** The current kernel
opens `SLIMBUS_0_TX` capture with topology `0x10315`, app type 69938, and ACDB
device 4, then parses and sends the board ACDB's complete 524-byte AudProc
table. Live dmesg confirms `SLIMBUS_0_TX applied ACDB AudProc calibration:
device=4 rate=48000 app=69938 (524 bytes)`, but capture remains exactly zero.
This eliminates the selected COPP topology plus AudProc table as a complete
fix; Android also sends the separate AudVol table.
**AFE calibration delivery audit — 2026-07-14:** All three local Pixel
Handset ACDB variants agree. Device 4 has no `AFECLUT0` common-calibration
row, and its `AFE_CMN_TOPID_V2` device property is `0x000112fb`, Qualcomm's
`AFE_TX_TOPOLOGY_ID_NONE`. The only device-4 AFE datum is a 48-kHz AV-sync
delay of 578, which cannot account for an all-zero stream. Qualcomm's SDM670
ACDB loader passes the same device ID 4 to AFE (there is no hidden remap to
the unrelated AFE-common IDs 100/128/130/149), tries topology, common table,
then hardware delay. Therefore adding an AFE common/topology sender here
would deliver no microphone payload. Do not revisit AFE delivery without new
Android evidence.
**ADM AudVol + explicit SLIM-error test — 2026-07-14 (negative):** Device 4,
app type 69938, volume index 0 decodes to a 40-byte table: soft-volume
stepping parameters and mono gain `0x2000` (unity). Kernel
`7.1.1-sdm845-gfb8f067e12f2` parses `AVOLLUT0`/`AVOLCDFT`/`AVOLCDOT` with the
same validated generic table builder and sends AudProc then AudVol, matching
Android's order. The same build propagates previously ignored failures from
SLIM port connection and WCD934x stream prepare/enable. A controlled 5-second
`DMIC4 -> DEC7 -> TX7 -> MultiMedia2` mono 48-kHz capture completed normally
and produced 480,000 bytes / 240,000 samples, all exactly zero. Live dmesg
confirms `SLIMBUS_0_TX applied ACDB AudProc/AudVol calibration: device=4
rate=48000 app=69938 (524/40 bytes)` and contains no capture-time SLIM
connect/prepare/enable, WCD934x, Q6, permission, or missing-file error.
Therefore neither the missing AudVol table nor a silently discarded SLIM
setup failure explains the zero stream.
Do not stream the ADSP-owned `217:250:0:0` debugfs regmap `registers` file
during capture: a filtered read blocked after the capture had completed and
had to be killed. This is consistent with the earlier observation that IFD
`0x097` is controlled by the ADSP SLIM master; it is not a safe codec-style
bulk register snapshot path and yielded no new state evidence.
**True cold-boot re-validation — 2026-07-13:** Kernel
`7.1.1-sdm845-g44d43e6ef336` includes the WCD934x `.prepare`/`.shutdown`
stream-lifecycle experiment. On a physical shutdown/power-on with native WCN
boot healthy, the controlled DMIC4 → DEC7 → TX7 → MultiMedia2 raw capture was
again exactly zero (`192000` bytes, `0` non-zero bytes). The temporary
`mic-ngd` trace proves the entire kernel-visible sequence ran successfully:
`q6afe_port_start ret=0`, `slim_stream_enable` entered,
`qcom_slim_ngd_enable_stream` entered and returned `0`. There was no SLIM/Q6
timeout. ALSA was restored immediately; the three HPH-impedance restore errors
are documented read-only controls. **This falsifies the prepare-order patch as
a microphone fix and makes silent ADSP-side channel activation (not userspace,
Q6 return handling, or NGD error propagation) the current boundary.**
**Stable-SLPI follow-up capture — 2026-07-13:** After the repaired sensor
registry cleared CHRE's five-minute watchdog and the SSC desktop sensor clients
were exercised successfully, the same safe single-direction TX7/DMIC4 route
was captured as 48 kHz mono raw audio for five seconds. It produced 480,000
bytes / 240,000 samples, all exactly zero. ALSA state was restored by trap;
SLPI, hexagonrpcd, and iio-sensor-proxy stayed active, with no `MC:0x2c`,
`-110`, or CHRE fatal. The sensor repair therefore improves platform stability
but does **not** open the microphone path.
**NGD/update audit — 2026-07-13:** The running 7.1.1 source already contains
the complete upstream May-2026 NGD probe/SSR race-fix series that landed for
7.2-rc: deferred IRQ enable, controller-owned workqueue initialization, safe
SSR/PDR cleanup, and the `tx_lock` ABBA deadlock fix. It therefore must not be
re-applied as a speculative microphone patch. This boot still logged one
`QMI wait timeout`; that is the driver's one-second wait for the remote QMI
service, not an `EPERM` or file-access failure. It remains a boot-stability
lead, but the subsequent raw capture's core `CONNECT_SOURCE` transaction
returned `0` and the audio data was still all zero.
- The on-device session's mic doc (collected to
`docs/tasks/mic-slim-tx-20260712.md`, source
phone `~/projects/unfinished/pixel3-microphone/`) found every capture
start at ~23h uptime logging 3x `TX timed out:MC:0x2c` /
`failed:-110` — the SLIMbus `CONNECT_SRC` user message to the ADSP
master never answered — and called that the localized root cause.
- **Re-test after a WARM reboot (same day, laptop-driven): the 0x2c
timeout did not reproduce — but the boot was NOT clean.** That boot was
produced by `sudo reboot` (warm), and its dmesg shows `QMI wait timeout`
at 8.1s plus the repeating "Rcvd master capability" retry loop — the
documented degraded slim-ngd state that warm reboots carry over (same
TZ-poison family as the WiFi MSA issue; only an UNPLUGGED cold power-off
clears it). Within that caveat: a `hw:0,1` capture with the doc's exact
TX7/DMIC4 arming logged 37 slim transfers — all MC `0x60`/`0x68` value
messages, zero errors, zero timeouts — and was still bit-for-bit zero,
with IFD `0097/0320/0330/0970` all `00` mid-capture. **Both datapoints
(0x2c timeout at 23h uptime; silent no-activation here) need
re-validation on a true cold boot before either is trusted.**
- No root-cause conclusion is valid yet. The `-110` may be a degraded-NGD
artifact of long uptime / remoteproc restarts, while the silent all-zero
capture may be a separate normal-state failure; the only attempted contrast
was tainted by a warm reboot. Kernel-visible Q6 and NGD success plus Android's
`IFD 0x097=21` versus mainline `00` remain observations, **not a proven
boot-invariant activation failure**.
- Note: `0320/0330` read `00` here vs `c0/01` in the 07-11 canonical 2ch
trace — arming differed (single TX7 vs TX7+TX8); observation only.
- What the phone doc contributes regardless: OnePlus 6 (enchilada) mic
works on pmOS 6.x kernels with this same driver stack (6.x->7.x
regression candidate in slimbus/ngd/wcd934x, or blueline-specific ADSP
behavior); pmOS's blueline UCM ships with the whole mic section
commented out (nobody has solved this on mainline); operational
hazards — never restart the adsp remoteproc while debugging slim (NGD
stays degraded until reboot, reproducible), never leave MultiMedia2
with both `SLIMBUS_0_RX` and `SLIMBUS_0_TX` routes enabled (q6adm/q6asm
wedge); QUAT_TDM_TX_0 in DT would give a WCD-free CS35L36 VMON/IMON
capture reference.
- Refined next steps: trace the `qcom_slim_ngd_enable_stream` user-message
exchange on a fresh boot (is CONNECT_SRC sent and ACKed, or skipped?);
diff `drivers/slimbus/{qcom-ngd-ctrl.c,stream.c,messaging.c}` +
`wcd934x.c` against pmOS's 6.x sdm845 tree; if an enchilada is handy,
boot this 7.1.1 kernel on it to split regression vs blueline-specific;
ask #sdm845-mainline about silent no-activation with working value
messages.
### Upstream/device-branch archaeology — 2026-07-12 (no phone test)
- The current `sdm845/7.1-dev` upstream line is active (its tip is two months
newer than our 7.1.1 base) but its audio delta is the CS35L36 speaker DTS
support already mined for the working speaker route; it contains no WCD934x
microphone/SLIM-TX fix. Do not hold a cold-boot test for an imagined pending
7.1 microphone update.
- **Real candidate to test after a true cold baseline:** historical
`joel/op6-audio-fixes-wip` commit `1d5776ca` changes WCD934x SLIM lifecycle
from `.trigger` (enable on PCM START) to `.prepare` plus `.shutdown` (enable
before START, disable on close). Our current `wcd934x.c` still has the old
`.trigger` implementation. This is not upstream and not proof of a fix, but
it moves the `slim_stream_enable()` / CONNECT_SRC exchange out of PCM START
into the backend prepare phase. Static inspection confirms the Q6 SLIM DAI
starts its AFE port in `.prepare`, while DPCM prepares BEs before the FE;
that makes this a concrete stream-ordering hypothesis rather than a generic
codec tweak. First make an instrumentation-only patch or trace plan that
establishes the exact per-DAI callback order; only then consider a
rollback-approved kernel test.
- Related branch commits were inspected and are **not** default candidates for
blueline DMIC capture: `75ad5bb0` adds separate AIF2/AIF3 SLIM DAI links for
OnePlus use cases (our AIF1 `SLIMBUS_0_TX` link already matches its AIF1
portion); `4a05bee2` and beryllium `07078b5c` repair MBHC/MIC_BIAS2 headset
handling, not the DMIC4/MIC_BIAS4 path. Keep them as topology references,
not a grab-bag patch series.
- **Candidate build/deploy and cold-boot result (2026-07-13):** the lifecycle
change was ported exactly onto the running Type-C-bisect base
(`56b0a053b`) as `44d43e6ef` / Gitea branch
`mic-slim-prepare-order-g56`, built on ArchDev, module tree installed, and
boot image flashed to slot A. Casey then performed an unplugged shutdown and
power-on; on `7.1.1-sdm845-g44d43e6ef336`, the controlled
`DMIC4 → DEC7 → TX7 → MultiMedia2` `hw:0,1` capture still contained only
zero samples. No `MC:0x2c` / `-110` occurred during that capture. Thus the
prepare-order hypothesis is a valid deployed negative result, not an
untested lead; retain the kernel as the current microphone-test baseline.
## Live state — 2026-07-12 (speakers)
- BOTH speakers now fire: the earlier "speaker playback works" state was in
fact top-speaker-only — both CS35L36 amps had `Channel Mux = RX1`, so the
bottom loudspeaker never received a channel. Fixed with the pmOS backup
image's routing (Left=RX1 top, Right=RX2 bottom, plus LDM select / PDM
ramps / zero-cross / per-amp ASPTX sources) in the overlay UCM
(commit 2f39c06), installed on-device and persisted via `alsactl store`.
Verified by ear: distinct left/right/stereo tones.
- Phone-side handoff doc `~/projects/unfinished/pixel3-speaker-routing/`
(README + baseline state + test tones) documents the diagnosis trail;
its "next step" (pmOS MRs online) was superseded by reading the local
pmos-20260703 rootfs image directly (debugfs, no mount needed).
- **Regression and guardrail — 2026-07-13:** the live TDM split was still
correct (`Left Channel Mux=RX1`, `Right Channel Mux=RX2`), but both amp and
boost switches were off. Re-enabled all four and stored the corrected state
on the phone. `docs/tasks/asound-baseline-20260712.state` is a *pre-fix
diagnostic snapshot* (`Right Channel Mux=RX1`); it must never be passed to
`alsactl restore`, because doing so regresses the bottom speaker. Use the
deployed UCM and current `/var/lib/alsa/asound.state` as the restore source.
## Prior live state — 2026-07-11
- Speaker playback works end-to-end through PipeWire, UCM, QUAT TDM and the
CS35L36 amplifiers (top speaker only — see above).
- `arecord -D hw:0,1 -f S16_LE -r 48000 -c 2` (the canonical MultiMedia2
front-end, whose `SLIMBUS_0_TX` link is enabled) opens and runs, but capture is
bit-for-bit zero. This is a hardware/ASoC transport investigation, not a
PipeWire source-selection failure; no PipeWire source can exist until ALSA
produces samples.
- This work did not start `iio-sensor-proxy`. There is no evidence that the
sensor-client HACK or SLPI wake-lockup mechanism gates this audio path.
## Verified zero-capture path — historical 2026-07-11
The controlled route is Android's documented handset/endfire pair:
- DMIC4 -> DEC7 -> SLIM TX7 and DMIC3 -> DEC8 -> SLIM TX8.
- Q6 function tracing during `arecord` observed, in order:
`q6slim_set_channel_map`, `wcd934x_hw_params`,
`q6afe_slim_port_prepare`, `q6afe_port_start`, and `wcd934x_trigger`.
- A temporary argument probe observed the two expected shared-channel IDs
delivered to Q6 when TX6 is off: `tx_num=2`, `0x87`, `0x88` (135, 136).
The resulting 478,078 signed-16 samples on `hw:0,1` were all zero.
- The WCD9340 interface device (`217:250:0:0`, `WCD9340-IFC-DEV`) receives
the expected driver writes for both ports: TX7 map/config `0x11c=80`,
`0x11d=01`, `0x57=05`; TX8 `0x120=80`, `0x121=01`, `0x58=05`.
Its live interrupt enables are `0x32=c0` and `0x33=01`, so their absence is
**not** the explanation for silence.
- On that same canonical front-end, `q6afe_port_start()` returns `0`, then
`slim_stream_enable()` invokes `qcom_slim_ngd_enable_stream()`, which returns
`0` after the controller's `DEF_ACT_CHAN` and `RECONFIG_NOW` operations.
Kernel-visible Q6 and NGD schedule activation therefore succeeded.
- **Corrected DAPM observation:** a clean live `hw:0,1` capture powers
codec-side `AIF1 CAP` and `AIF1_CAP Mixer`. Its prepare phase calls
`wcd934x_codec_enable_slim` and two `wcd934x_codec_enable_dec` events.
The earlier report that these callbacks never fired was false: the trace
missed the prepare-phase calls. Do not use that earlier result as evidence.
- The *persistent* mixer state leaves `CDC_IF TX7 MUX` and `CDC_IF TX8 MUX`
at `ZERO`, despite the corresponding AIF mixer switches and DMIC muxes
being selected. Consequently the TX7/TX8 branch is off during an ordinary
capture and no `wcd934x_codec_enable_dmic` event occurs. This is a real UCM
route omission, not an ADSP conclusion.
- A controlled, automatically reverted test set those muxes to `DEC7` and
`DEC8` and disabled stray TX6. It powered the entire intended branch and
invoked `wcd934x_codec_enable_dmic` twice (with matching shutdown calls).
The independent two-second PCM capture was nevertheless 384,000 zero bytes.
Thus the codec DAPM path and physical DMIC endpoints are viable once the
muxes are selected, but that route omission is not the final silence cause.
- This is **not** a missing FE-to-BE connection: runtime ASoC state reports
`MultiMedia2 Capture: start` with `SLIM Capture 1: start` as its active
backend, and the codec's AIF/decimator event callbacks run. With the CDC
muxes selected, the DMIC callbacks run too; the unresolved point at that
date was after the fully powered codec capture path.
- Reducing the route to the downstream-style single TX7/DMIC4 channel did not
change the result: a four-second `hw:0,1` mono capture contained 192,000
zero samples. Channel count/configuration is therefore not the activation
trigger.
## What the 2026-07-11 evidence did and did not say
Android's captured recording state has IFD `0x097=21`; mainline reads `00`.
During a five-second live TX7/TX8 capture, writing `0097 21` through the
debugfs regmap returned success but read back `0097: 00`, and all 478,078
samples remained zero. This confirms that a userspace register replay cannot
enable that state on this path. It does **not** establish what `0x097` means
or prove that it is the root cause. Do not turn it into an unconditional
codec write or call it an “ADSP-master fix” without an implementation-level
source or Android-side transition capture.
TX6 is enabled by the current mixer default alongside TX7/TX8. It makes the
unconstrained map three channels (`0x86`, `0x87`, `0x88`), while disabling it
produces the correct TX7/TX8 pair above. That is a real UCM/machine-routing
cleanup item, but it did not restore capture and is not the root cause.
## Proposed next work on 2026-07-11 — superseded
1. Capture the working Android interface-device transition, or find the
downstream owner/meaning of IFD `0x097`; compare the actual write sequence,
not just idle/recording register snapshots.
2. Add the TX7/TX8 `CDC_IF` mux selections to the eventual microphone UCM
enable sequence (and keep TX6 off for this two-channel route). Do not
expose a broken PipeWire source before its capture is non-zero.
3. Repeat the WCD9340 interface/ADSP comparison only with that fully powered
codec path. The still-zero full-path test strengthens, but does not prove,
the relevance of the non-sticking Android IFD `0x097=21` delta. Capture an
Android transition or find the downstream owner before making a firmware
or register claim. Do not flash a kernel test without an explicit
rollback-approved deployment plan.
4. Only after that, compare the remaining post-activation state with Android
at the firmware boundary. Q6 and NGD success alone do not show that the
codec/ADSP hardware emits decimator samples.
5. Fix the stray TX6 default separately in the persistent UCM/machine route,
then verify it with the channel-map probe. Do not claim mic support until a
live capture contains non-zero samples.
## Instrumentation
`/usr/local/sbin/blueline-lockup-trace` is a root helper deployed from
`rootfs-overlay/`. `mic-start` traces the Q6/WCD stream functions and the
three WCD codec DAPM event callbacks; `mic-map-start`, `mic-ifc-start`, and
`mic-ngd-start` collect Q6 channel-map, WCD interface-register-write, and
Q6/NGD return traces respectively. Trace sessions are temporary and must
always be paired with the matching `*-stop` command; the current phone was
checked clean afterwards (`tracing_on=0`, tracer `nop`, no kprobes).
## 2026-07-18 full Android power-state reconciliation
A clean, single-channel PulseAudio/UCM capture on kernel `4c3a94153` proved
that the intended TX7/DMIC4 path is selected and fully ACKed, but every one of
55,680 S16 samples is exactly zero. A simultaneous live codec dump exposed
two remaining Android/mainline power-state differences which earlier tests had
not actually eliminated:
- `ANA_MICB4` is `0x50` on mainline versus `0x90` during Android recording.
The DT opt-in `qcom,blueline-dmic-micbias-pullup` is on the `codec@1,0`
node, but `wcd934x_codec_parse_data()` queried `dev->parent->of_node` (the
SLIM controller). Therefore `micbias_pullup` was always false and the
earlier claim that pull-up mode had been tested is invalid. The code now
queries `dev->of_node`, selecting Qualcomm's downstream
`MICB_PULLUP_ENABLE` path (`0x90`).
- `ANA_BUCK_CTL` is `0x00` on mainline versus `0x07` on Android. Qualcomm's
resource manager sets RCO followed by buck `PRE_EN1`, `PRE_EN2`, and
`HIGH_ACCURACY_EN`, with 100 us between stages. The mainline driver had
dropped this sequence. It is restored as ordered masked writes, including
the reverse transition; this is not the harmful unsequenced Android
end-state replay removed earlier.
The same correction (`a75371b49`) also matches Android's board state by
programming only DMIC interface 3 pads (the real DMIC3/4 inputs) and avoids
leaving TX7 at the transient 150 Hz HPF setting (`CFG0=0xd0`) indefinitely;
Android's steady recording state is `CFG0=0x90`. One boot-time log reports
whether pull-up mode was parsed, and the capture log reports live BUCK and all
MICB registers so the next capture validates the complete state in one pass.
## 2026-07-18 eFuse initialization regression and cache fix
On the clean `3b85e688f` boot, the complete downstream AFE codec-control map
registered successfully and TX7 again reached `port_start`, CONNECT_SOURCE,
DEF_ACT_CHAN, and RECONFIG_NOW with positive ACKs. PulseAudio captured 760,318
raw bytes (380,159 S16 samples), all exactly zero. The journal exposed a real
codec boot failure: `wcd934x_enable_efuse_sensing` read `EFUSE_STATUS=0` and
reported that sensing never completed.
History showed that `1c095f7a7` had added the downstream-required
internal-SIDO start before eFuse sensing, but `c1b6371c6` removed the call while
dropping unrelated experiments. The exact downstream SIDO/buck transition
helper was later restored by `a75371b49` without reconnecting it to eFuse init.
The audit also found that downstream treats `EFUSE_CTL`, all eFuse value
outputs, and status as volatile, while mainline cached them in `REGCACHE_MAPLE`.
Commit `82355eac0` batches the complete correction: internal SIDO before the
sense enable, the required 5 ms delay before RCO/BG, downstream-parity volatile
register handling for the eFuse/clock/buck sequence, live completion polling,
register error propagation, and explicit status/out14/out15 logging. Do not
interpret another zero capture until a cold boot proves the codec prints
`eFuse sense complete`; otherwise the physical codec trim/version state is
still uninitialized even though SLIM management commands ACK normally.
View git blame Copy permalink