FP3 (SDM632/msm8953): WCD9326 (Tasha-lite) SLIMbus framer never comes up on mainline — earpiece/in-call/mic silent

[llg179]

The issue was investigated on my device by Anthropic's Claude code with Opus. See "What we're asking" section on how to make SLIMbus framer come up.

Summary

On a mainline kernel (postmarketOS, msm8953-mainline) the LPASS/ADSP never becomes
SLIMbus framer master, so the WCD9326 (Tasha-lite) codec never gets a logical address.
Result: earpiece / in-call / mic are silent (only the aw8898 speaker on Quinary MI2S
works). The AP-side satellite NGD sits waiting for a capability/reconfiguration that
the ADSP framer never drives.

We have exhaustively ruled out the AP/kernel side and would like a pointer from the
BSP side (details/ask at the bottom).

Environment

• Device: Fairphone 3 (FP3), SoC SDM632 (msm8953), codec WCD9326 (Tasha-lite) on SLIMbus (c140000.slim-ngd). The codec is bound by the mainline wcd9335 driver (Tasha family), so dmesg reads wcd9335-slim; ALSA card is msm8953-tashalite-snd-card.
• OS: postmarketOS, kernel 7.0.9-msm8953 (msm8953-mainline tree), lk2nd chainload.
• Firmware: stock FP3 adsp.mbn (Oct-2021 build). XBL / ABL / TZ / RPM / ADSP firmware are all identical to the stock Android boot — only boot.img is replaced by lk2nd.
• Reference: on msm8996 (full WCD9335/Tasha, same codec family, same mainline driver) the mainline SLIMbus stack brings the framer up correctly; on msm8953 it does not (family-wide: same pattern on sdm660/sdm670). This points at the msm8953 LPASS/ADSP side, not the codec variant.

Symptom (exact, reproducible)

qcom,slim-ngd-ctrl c140000.slim-ngd: DBG power_up: QMI power request OK
qcom,slim-ngd-ctrl c140000.slim-ngd: DBG power_up: ver=0x105 ngd_status=0x40c
qcom,slim-ngd-ctrl c140000.slim-ngd: DBG power_up: NGD setup done, waiting for capability (reconf)
qcom,slim-ngd-ctrl c140000.slim-ngd: capability exchange timed-out STATUS=0x40c CFG=0x0 INT_STAT=0x0
qcom,slim-ngd   qcom,slim-ngd.1: TX timed out:MC:0xd,mt:0x2
wcd9335-slim 217:1a0:1:0: Failed to get logical address

• INT_STAT=0x0 over the whole timeout window: the NGD receives zero interrupts —
  the ADSP never frames the bus (never sends SLIM_USR_MC_MASTER_CAPABILITY).
• Reproducible on demand via a clean ADSP restart:
  echo stop > /sys/class/remoteproc/<adsp>/state; echo start > .../state
  → adsp is now up, APR audio services register, then the exact same
  ngd_status=0x40c → waiting for capability → timeout → Failed to get logical address.

Ruled out (AP/kernel side)

• QMI SLIMbus (SvcId 0x301): SELECT_INSTANCE + POWER_REQ payloads and sequence
  are byte-identical to the working downstream capture; POWER_REQ returns OK.
• TZ/PAS bring-up: mainline qcom_q6v5_pas vs downstream subsys-pil-tz use the
  same PAS SCM path (init_image → mem_setup → auth_and_reset); equivalent.
• SMEM, clocks (incl. bb_clk1), regulators, power-domains, pinctrl: present/identical.
• Firmware swap: flashing the authentic stock adsp.mbn on mainline does not change it.
• NGD register programming: identical to the mainline msm8996 reference (where it works).
• msm8996 vs msm8953: the only DT delta is the LPASS SMMU/GDSC that msm8953 lacks in
  HW — not a fix, but it shows msm8953's LPASS is "AP-opaque".

Golden reference (working downstream, driver-internal ipc_logging)

Captured live on the FP3 stock 4.9.218 stack (/d/ipc_logging/c140000.slim), the
working framer bring-up is entirely ADSP-driven — the AP is a passive satellite:

[22.960] Slimbus QMI NGD CB received event:2   (QMI_SERVER_ARRIVE, SLIMbus SvcId 0x301)
         QCCI TX MI:0x20 ML:0x15 SvcId:301     (SELECT_INSTANCE req)  -> RX OK
         QCCI TX MI:0x21 ML:0x0e SvcId:301     (POWER_REQ req)        -> RX OK
[22.989] SLIM SAT: Rcvd master capability      (ADSP broadcast MASTER_CAPABILITY on the bus)
[22.989] SLIM SAT: capability exchange successful
         slimbus:1 laddr:0xc8 / laddr:0xc7      (codec enumerated)

The AP does only SELECT_INSTANCE + POWER_REQ on SvcId 0x301; it never sends
CHECK_FRAMER (MI:0x22). ~1.3 ms after POWER_REQ the ADSP frames the bus and the AP's
NGD RX message queue receives SLIM_USR_MC_MASTER_CAPABILITY, to which it replies with
SLIM_USR_MC_REPORT_SATELLITE. The AP cannot and does not drive the framer — it waits
for the ADSP to broadcast capability.

On mainline the two QMI requests are byte-identical and the ADSP accepts them (POWER_REQ
returns OK), but the master-capability broadcast never happens. Decoding the failing
NGD registers confirms it precisely:

• STATUS=0x40c → NGD_LADDR (BIT1) is clear: the framer never enumerated the NGD.
• INT_STAT=0x0 → NGD_INT_RX_MSG_RCVD (BIT30) is clear: the NGD received zero
  slim RX messages — the ADSP never put MASTER_CAPABILITY on the bus.
• CFG=0x0 → even though the AP writes NGD_CFG = RX_MSGQ_EN|TX_MSGQ_EN|ENABLE (0x7)
  during setup, it reads back 0 one second later: the NGD is never handed to the AP
  because the framer never framed.

New finding (ADSP side, via rpmsg diag on mainline)

We exposed the ADSP's own DIAG SMD channel through rpmsg_char and read its F3 log
during the reproduced framer failure:

• The ADSP boots fine and its APR audio services register.
• During the framer failure the ADSP emits zero unmasked/error F3 — it does not
  treat "SLIMbus not framed" as an error/assert.
• Interpretation: the framer-master role is simply never triggered/requested on
  mainline; the ADSP isn't failing, it's never asked to frame.
  (We could not enable masked/debug F3: binding the ADSP DIAG_CNTL control channel
  triggers a firmware/TZ-level SoC reset without the proprietary diag handshake — so the
  masked debug log needs your build's diag .dci DB / QXDM.)

What we're asking (answerable with BSP access)

1. On mainline the ADSP accepts the SLIMbus POWER_REQ (QMI OK) but never broadcasts
   SLIM_USR_MC_MASTER_CAPABILITY on the bus (NGD_INT_RX_MSG_RCVD never fires). On your
   downstream boot the identical POWER_REQ is followed ~1.3 ms later by the ADSP framing
   the bus. What, beyond SELECT_INSTANCE+POWER_REQ on SvcId 0x301, makes the ADSP
   actually start framing and broadcast master capability? An ADSP boot argument, a
   device.cfg/ACDB/static-image config flag, or an SMD/GLINK/APR handshake it expects?
2. Is the framer election gated by an ADSP-firmware config (ADSP static image /
   device.cfg / ACDB) that is present in your downstream boot but absent on a bare
   mainline boot?
3. Does the audio userspace (ACDB loader / audio HAL) send an early
   AFE/SLIMBUS command that kicks off the framer? (On downstream the framer comes up
   ~25 ms after ADSP boot, before the audio HAL — suggesting it's ADSP-internal, but we
   want to confirm.)
4. If possible: a QXDM / ADSP diag F3 capture of the SLIMbus framer bring-up on a
   working downstream boot (and/or of the failing mainline case). The .dci message DB
   is build-specific and only available on your side, so this is the one artifact we
   cannot produce ourselves.

Suspected mechanism (hypothesis — for BSP/QXDM verification)

We cannot see inside the ADSP, so the following is a hypothesis, not a claim. Given that
the AP side is byte-identical (QMI), the firmware is bit-identical (verified by loading
the authentic stock adsp.mbn on mainline — still silent), SMEM is bit-identical, the
ADSP load address matches (0x8d600000), and the PAS SCM sequence is equivalent
(PAS_INIT_IMAGE/AUTH_AND_RESET, pas-id=1, no restore_sec_cfg, no extra SMC —
downstream also uses qcom,pil-tz-generic, i.e. the same PAS path), the divergence
appears to live in the ADSP firmware's early SLIMbus-controller init branch behaving
differently under a mainline PAS boot vs a downstream boot — e.g. an xPU/access-control
or internal LPASS clock/reset that is implicitly opened during the downstream
auth_and_reset, or a platform-context/role variable that leaves the ADSP in a
"satellite/slave" state where it waits to be framed instead of framing.

Concrete questions for someone with source/QXDM access:

1. In the msm8953/sdm632 ADSP image, what internal variable or register gates the early
   SLIMbus-controller init branch (the framer-master vs satellite/idle decision)?
2. During auth_and_reset (pas-id=1), does the downstream TZ/PIL path implicitly open an
   LPASS/SLIMbus xPU or ungate an internal LPASS clock/reset that the mainline PAS path
   does not? (Note: on mainline MI2S/LPAIF works, so the LPASS is powered — this would
   have to be SLIMbus-macro-specific.)
3. The SoC-ID/platform-subtype the ADSP reads is XBL-populated (identical on both boots),
   so a SoC-ID branch alone cannot explain it — is there a Linux-stage PAS-vs-PIL
   handoff difference (a scratch/context value the downstream stack writes before the SMC)
   that the ADSP consumes? If so, which one?
4. A QXDM / ADSP diag F3 capture of the SLIMbus framer bring-up on a working downstream
   boot (the .dci DB is build-specific and only available on your side).

Any pointer to the trigger would unblock mainline audio on FP3 (and likely the whole
sdm6xx family). Thanks!

[llg179]

Attaching the raw evidence behind the report, plus one new data point we collected since writing it.

Attachments

• pmos-dmesg-full.txt — fresh full boot dmesg from the failing mainline stack (7.0.9-msm8953). The kernel carries two local debug patches in qcom-ngd-ctrl.c (extra prints around the capability wait, and a force-enabled bb_clk1 — one of the ruled-out experiments); everything else is stock.
• downstream-golden-ipc-trace.txt — annotated /d/ipc_logging/c140000.slim capture of the working downstream (4.9.218) framer bring-up, two boots. This is the golden reference quoted in the report, with the QMI length decoding (the handshake is byte-identical to mainline once the 7-byte QMI header is accounted for).
• pmos-slim-ctx-devmem.txt / ut-slim-ctx-devmem.txt — /dev/mem dumps of the NGD/BAM registers and the SMEM TOC header, taken on both stacks (we rebuilt the downstream 4.9.218 kernel with CONFIG_DEVMEM to get the working-side view).
• pas-launch-diff.txt — source-level, side-by-side diff of the full ADSP launch path (mainline qcom_q6v5_pas vs downstream subsys-pil-tz): the SMC ABI, PAS command sequence, pas-id, load address and carveout are equivalent, which is the basis for the "TZ/PAS bring-up ruled out" claim in the report.

New finding since the report (/dev/mem on both stacks)

1. SMEM is not the differentiator. The SMEM TOC/heap header at 0x86300000 is byte-identical between the working downstream boot and the failing mainline boot, except a single item offset (0x14ba8 vs 0x14b58). So a "downstream boot-chain populates an SMEM flag the ADSP reads" theory has no support in the AP-visible SMEM area we compared.
2. Register-access asymmetry confirms the ADSP-owns-SLIMbus model. On the working downstream stack the AP cannot read the NGD/BAM block at all while idle (uniform bogus 0x70 readback; a subsequent access hard-hung the AXI bus into Qualcomm dump mode) — the SLIMbus block is clock-gated/owned by the ADSP. On the failing mainline stack the AP reads the NGD fine (its driver holds the clocks) but the ADSP never frames. In other words: when the framer works, the block belongs to the ADSP; when the AP owns it, the framer never comes. That is consistent with the trigger living inside the ADSP firmware's boot environment (PIL-vs-PAS), not in anything AP-visible.

Also worth stating explicitly: adsp.mbn on FP3 is a relocatable image (bit 27 set on the loadable segments), so mainline's mdt_loader does call PAS_MEM_SETUP exactly like downstream — the launch sequences don't diverge even there (details in pas-launch-diff.txt).

Happy to run any experiment on either stack — we have both booting on the same device (A/B slots) with /dev/mem available on both.

downstream-golden-ipc-trace.txt
pas-launch-diff.txt
pmos-dmesg-full.txt
pmos-slim-ctx-devmem.txt
ut-slim-ctx-devmem.txt

[llg179]

Fairphone 3 mainline SLIMbus framer never comes up on mainline @z3ntu

[z3ntu]

I've never had any luck with WCD on FP3 either, I think this is one of the most recent branches (from 2022) https://github.com/z3ntu/linux/commits/msm8953-5.16-fp3audio/ But nothing much more I can offer here

[llg179]

Thanks Luca! Claude code (with me) went through the three FP3-audio commits on that branch
(e49f019a, 7822cb3e, dc4249d5) and compared them with our current tree —
good news is they fully corroborate each other: our DT already carries the
equivalent plumbing (slimbam + slim-ngd, wcd9335/tasha_ifd with reset on
tlmm67 and IRQs on tlmm73/74, pm8953 GPIOs), and everything in the branch is
AP-side, so your "never had any luck" is an independent confirmation that this
wall has been standing since 2022 and lives on the ADSP side. Two useful
details I'm folding in from your branch for post-framer bring-up: the MCLK
wiring (DIV_CLK2 gated by PM8953 GPIO1 via gpio-gate-clock) and the codec
supply question (your tlmm-gpio50-gated 1.8V fixed regulator vs. our L5 rails
— I'll verify against downstream).

Since 2022 we've been able to push the diagnosis quite a bit further (all in
the issue above): the QMI handshake is byte-identical to the working
downstream boot and the ADSP ACKs it; the NGD receives literally zero
interrupts during the capability wait (INT_STAT=0x0 the whole window); we
force-enabled bb_clk1 (which your branch also identified as SLIMBUS_CLK, left
commented out) with no effect; SMEM is byte-identical across the two boots;
and the PAS/PIL SCM sequences are equivalent down to the SMC ids. Everything
AP-visible is exhausted — the framer trigger is inside the ADSP firmware's
boot environment.

Which is why the one thing that would really unblock this is BSP-side: a QXDM
/ ADSP diag F3 capture of a working framer bring-up (the diag .dci message DB
is build-specific), or a look at what gates the SLIMbus framer-master election
in the SDM632 ADSP image (device.cfg / ACDB / static image config). No
pressure at all and fully understood this isn't your job — but if you ever
happen to be near the SDM632 BSP or know whom one could ask (I've also filed
Fairphone support ticket #1453513 asking them to route this to the software
team), a pointer would likely unblock audio for the whole msm8953/sdm6xx
family. Happy to run any experiment on the device — I have instrumented
mainline and downstream kernels booting A/B with /dev/mem access on both.

[z3ntu]

Just remembered, try these patches, they do fix some real issues https://lore.kernel.org/lkml/20260331-slim-ngd-dev-v2-0-9441e9c8420e@oss.qualcomm.com/ they should be in linux-next but looks like not yet in a release.

At least on sdm845 there's been more progress regarding bluetooth slimbus with these patches, before some roadblocks regarding slimbus were hit.

[llg179]

Thanks for the pointer — I (Claude code's Fable 5) tested it right away. I applied the full v2 series
(all 7 patches, clean apply on our 7.0.9 tree apart from one trivial context
merge) and flashed: no change on FP3. The failure signature is byte-identical
— capability exchange timed-out STATUS=0x40c CFG=0x0 INT_STAT=0x0, codec
never gets a logical address.

That said, the series was worth running for two reasons: it does describe our
exact probe ordering (NGD probes after the ADSP remoteproc, so the SSR
notifier fires into the fresh driver — we see the same "HW wakeup attempt
during SSR" artifact), so it was a genuinely plausible AP-side suspect — now
ruled out. And the fixes are correct regardless, so we're keeping them in the
tree.

For completeness, two more null/positive results from today that sharpen the
picture (details in the comment above): a warm ADSP restart
(remoteproc stop/start in a fully-booted system) reproduces the failure
exactly, and the ADSP's AVS/APR audio framework is fully functional under
mainline (complete APR service set, ASM playback runs with rc=0). So the ADSP
is healthy and only the SLIMbus framer never starts — consistent with the
sdm845 experience you mention, where these patches helped the AP-side driver
but the remaining roadblocks were elsewhere.

[llg179]

Claude code's additional info:
Following up on the earlier AP-side elimination and the ADSP firmware disassembly
(external clock toggle decision, bb_clk1 ruled out): I now have register-level
ground truth from reading the SLIMbus core framer registers over /dev/mem, on
both a working reference and the failing mainline, using the same driver stack and
the same byte-identical adsp.mbn.

Method

• Working reference (framer UP): the FP3's downstream stack (Ubuntu Touch,
  kernel 4.9.218) loads the ADSP via subsys-pil-tz (PIL). The framer comes up and
  the WCD9335 enumerates. I built a CONFIG_DEVMEM variant of that exact kernel to
  read the live SLIMbus registers (the read is only safe while the SLIMbus core is
  clocked — I force-resume the controller / read under active audio; an idle read of
  gated LPASS MMIO hangs the AXI → dump mode, so this took some care).
• Failing side (framer DEAD): mainline (this tree) loads the same
  byte-identical adsp.mbn via q6v5-pas (PAS). The framer never comes up
  (capability exchange timed-out STATUS=0x40c CFG=0x0 INT_STAT=0x0, codec never
  gets a logical address).
• Both read the SLIMbus core at 0x0c140000. Framer register offsets are from
  the downstream slim-msm-ctrl.c (enum frm_reg: FRM_CFG=0x400, FRM_STAT=0x404,
  FRM_INT_EN=0x410, FRM_WAKEUP=0x41C, FRM_CLKCTL_DONE=0x420).

The comparison

register (base 0x0c140000)	UT / PIL — framer UP	mainline / PAS — framer DEAD
FRM_CFG @0x400	0x000D0C83	0x000D0C83 (identical)
FRM_STAT @0x404	0x060D1901	0x00000000
FRM_INT_EN@0x410	0x0000000B	0x0000000B (identical)
FRM_CLKCTL_DONE @0x420	0x00000000	0x00000000 (identical)
COMP_CFG @0x004	0x00000001	0x00000001 (identical)
NGD_CFG @0x1000 (our satellite)	0x00000007	0x00000000

FRM_CFG = 0x000D0C83 decodes exactly to the value the downstream framer-start
writes — (0xA << CLK_GEAR) | (1 << ROOT_FREQ) | (1 << FRM_ACTIVE) | 1 — i.e. the
framer config register (clock gear, root-freq select, FRM_ACTIVE) reads identical
on both. The one register that differs is FRM_STAT: on mainline the framer HW is
simply not running (0x0). It therefore drives no clock/frame, our satellite NGD
receives zero interrupts, and the codec never enumerates. This matches the AP-side
symptom exactly, but now pins it to the core: it is not a satellite/NGD problem and
not a config problem — the framer block is configured but the framer is not
clocked.

What is missing: the 24.576 MHz SLIMbus root clock

The downstream framer bring-up (slim-msm-ctrl.c) is:

clk_prepare_enable(dev->rclk);            /* core_clk @ SLIM_ROOT_FREQ = 24576000 (24.576 MHz) */
writel_relaxed(1, dev->base + FRM_WAKEUP);
writel_relaxed((0xA<<CLK_GEAR)|(1<<ROOT_FREQ)|(1<<FRM_ACTIVE)|1, dev->base + FRM_CFG);

The register state says the FRM_CFG/wakeup part is effectively in place, but step 1
— the 24.576 MHz SLIMbus root/core clock — is not running on mainline. On this
SoC that clock is generated inside LPASS and, on the NGD/satellite path, the ADSP owns
it. mainline msm8953 exposes nothing to drive it: no lpasscc-msm8953, nothing
SLIMbus in gcc-msm8953, and no SLIMbus clock ID in the q6afe clock controller.

The AP side has no handle — everything tested

• Writes don't latch: writing FRM_WAKEUP=1 and re-writing FRM_CFG from the AP
  read back 0 — the framer register block rejects writes while its clock is gated
  (same behaviour as our NGD_CFG=0x7 write never latching).
• No clock to enable: there is no SLIMbus/LPASS root clock in the Linux clk tree
  on either mainline or downstream; force-voting bb_clk1 (the only slim-adjacent
  clock, a fixed 19.2 MHz RPM XO buffer — not the 24.576 MHz root, which is not
  derivable from it) changes nothing in either state (driven or verified-silent).
• Audio doesn't trigger it: with the framer registers under live /dev/mem
  measurement, playing to Quinary MI2S (speaker) — and, previously, to
  SLIMBUS_0_RX — leaves FRM_STAT = 0. The MI2S and SLIMbus-root clock gates are
  independent.
• Asking the ADSP for the LPASS core clock over AFE is ACKed but doesn't help:
  we sent AFE_PARAM_ID_LPASS_CORE_SHARED_CLOCK_CONFIG (0x0001028C,
  AFE_MODULE_AUDIO_DEV_INTERFACE, {minor=1, enable=1}, the knob downstream uses
  on SDX/MDM SLIMbus platforms) right after ADSP-up. The ADSP accepts it (rc=0,
  no DSP error) — so the AP↔AFE path works and the firmware services clock
  requests — yet the subsequent capability-exchange attempts still time out
  identically and FRM_STAT stays 0. That param evidently gates the AHB/register
  core clock (reads already worked), not the SLIMbus root domain.
• The boot chain is identical across the working and failing boots: tz, rpm,
  devcfg, aboot, cmnlib(64), keymaster A/B partitions are byte-identical
  (cmp) — the same TZ/PAS binary and the same RPM firmware serve both the working
  downstream boot (slot a) and the failing mainline boot (slot b).

The question for SoC / ADSP folks

The framer clock is started by the ADSP internally. It starts it under PIL
(subsys-pil-tz) but not under PAS (q6v5-pas), with byte-identical firmware and
devcfg. Is there an AP-side precondition the PIL path establishes around ADSP
bring-up that the PAS path doesn't — an LPASS core/audio GDSC vote, a clock, a reset
deassert, or a devcfg/SMEM handshake — that the ADSP's SLIMbus-root-clock enable
depends on?

One concrete lead: mainline msm8996 does frame WCD9335 over PAS, and it has an
LPASS Q6 SMMU + HLOS1_VOTE_LPASS_ADSP_GDSC/HLOS1_VOTE_LPASS_CORE_GDSC that
msm8953 mainline lacks entirely. (Caveat: downstream msm8953 works without those, so
the exact precondition may be something else the PIL path asserts — but the
LPASS-power/clock direction seems the most likely place the young msm8953 mainline
support is missing a step the ADSP's framer-clock enable needs.)

Full register dumps, the FRM read/write scripts, and the boot traces are available on
request.