Re: SDM632 SLIMbus: ADSP framer never gets frame-sync under q6v5-pas (works under downstream pil-tz, identical firmware) - what physical precondition is PAS missing?

Hi Srinivas, all,

With the help of Claude Code it has been solved, playback works in the headset.
Fixable in the kernel - no TZ/PIL-internal change. The last difference
wasn't a PHY-pad or
 xPU precondition, it's a single AP-writable bit in the ADSP CSR:

  QDSP6SS 0x0c20002c, bit 3 (c200000.remoteproc aperture)
    downstream PIL leaves it clear (0x103); mainline PAS leaves it set (0x10b)

With bit3 set the framer never gets frame-sync (the INTF_STAT +0x604 = 0
loop I quoted); clear it and +0x604 reads 0x3e04, NGD capability completes,
the WCD9335 gets a logical address.

Timing subtlety that hid it: right after pas_auth_and_reset the bit already
reads clear, so clearing it there is a no-op - the ADSP re-sets it during
its own init. The clear has to land in the NGD path just before the
capability exchange. I do it in qcom_slim_ngd_power_up() before NGD_INT_EN,
gated by a DT property carrying the register address.

Verified on msm8953-mainline, 6.13 through 7.0.9, Fairphone 3: codec
enumerates, ALSA card comes up, and playback now reaches the headphone/
earpiece output (clean audio). A first-attempt capability timeout remains
(ADSP needs ~3 s; the existing NGD retry recovers it).

Two things I'd value your steer on before a series:

(1) Where should the register address live - per-board DT property on the
    NGD node (what I have), a soc-data quirk keyed off compatible, or the
    remoteproc side? This should help the whole SDM632/msm8953 + WCD9335
    family.
(2) Do you know what bit3 actually gates? A proper name/comment would turn
    it from a magic poke into a described fix - it behaves like something
    PIL ungates for the framer that PAS leaves gated.

WIP branch (personal fork, not for upstream as-is): github.com/llg179/linux,
branch fp3-709.

Thanks - and to Bert Karwatzki, whose working FP3 config was my reference.

Best regards,
László


Lajosházi László Gergely <[email protected]> ezt írta (időpont:
2026. júl. 20., H, 2:16):
>
> Hi Srinivas, all,
>
> On the Fairphone 3 (SDM632/msm8953, WCD9326 codec) mainline SLIMbus audio
> is silent: the NGD reports "capability exchange timed-out STATUS=0x40c
> CFG=0x0 INT_STAT=0x0" and the codec never gets a logical address. Same
> hardware works on the downstream 4.9 stack (A/B slots, same phone). With Claude
> code I've localized it to one register-level difference and I'm stuck
> on the last step.
>
> The only variable is the ADSP boot method: downstream subsys-pil-tz vs
> mainline qcom_q6v5_pas. adsp.mbn and its devcfg are byte-identical; the
> AP-side QMI sequence is byte-identical and ACKed in both cases; current
> mainline HEAD (including the merged qcom-ngd-ctrl fix series) reproduces
> it, cold-boot retested.
>
> Reading the SLIMbus block (0x0c140000) and LPASS-CC (0x0c000000) via
> /dev/mem on both slots:
>
>   reg (0x0c140000 +off)      downstream/PIL   mainline/PAS
>   FRM_CFG   +0x400            0x000D0C83       0x000D0C83   identical
>   INTF_CFG  +0x600            0x00000001       0x00000001   identical
>   FRM_STAT  +0x404            0x060D1901       0x00000000
>   INTF_STAT +0x604            0x00003E04       0x00000000
>
> LPASS-CC is byte-identical over the whole aperture (SLIMbus root RCGR
> CFG=0x509, branch CLK_OFF=0 on both -- the 24.576 MHz root clock runs on
> the dead side too). So the framer is configured and clocked identically;
> only the status registers read 0 under PAS: INTF_STAT bits FS/SFS/MS
> (frame/super-frame/master sync) never set -- the interface never acquires
> sync on the physical bus. The stock firmware's own bring-up confirms it
> waits on hardware: it polls the FS bit, times out ("Hardware failed to
> enumerate ... (FS:0)(SFS:0)(MS:0)"), and its subsequent HW reset succeeds,
> so ADSP register access is fine. The firmware maps no separate PHY/analog
> block. On msm8953 I find no AP-side lever either: no lpasscc, nothing
> SLIMbus in gcc, no LPASS GDSC (unlike msm8996, which frames the same codec
> family under PAS).
>
> Two questions:
>
> (1) What physical precondition (rail / reset-deassert / pad / LPASS-internal
> enable) must hold for the SLIMbus interface to acquire frame-sync on
> SDM632, and where does the pil-tz path establish it that q6v5_pas does not?
>
> (2) Is that step AP-reachable from mainline (SCM call, reset, regulator
> vote, clock, DT), or only TZ/PIL-internal -- i.e. is this fixable with a
> kernel patch at all, or does it need a vendor-side change?
>
> Full write-up, two-sided register dumps, binary diffs and the annotated
> firmware disassembly: https://github.com/msm8953-mainline/linux/issues/255
>
> Thanks for any pointer,
> László