Re: [RFC PATCH 0/8] ASoC: SDCA: enable on DT platforms and add Qualcomm WCD9378 (Tambora) codec

[Srinivas Kandagatla]

On 7/23/26 8:40 PM, Jorijn van der Graaf wrote:
> Hi Srini,
> 
> On Thu, 23 Jul 2026 00:42:10 +0100, Srinivas Kandagatla wrote:
>> The most obvious follow-up is figuring out how the mobile-mode and
>> compute-mode WCD9378 drivers coexist under one compatible.  Jorijn's
> [...]
>> tree without racing to bind the same slave.  I would like to line this
>> uip with Jorijn as a follow-up to this series.
> 
> Happy to line this up. To ground the discussion I ported the series
> onto my FP6 tree and have mobile-mode capture working end-to-end
> through the class framework, including PipeWire in Plasma — findings
> and a proposal below.
Thanks Jorijn for trying out and confirming that capture works.

> 
> 1) Arbitration, near term
> 
> Your probe already returns -ENODEV when qcom,compute-mode is absent;
> v2 of my mobile series will add the mirror check, so neither driver
> can bind the other's slaves regardless of probe order. If a single
> owner of the modalias is preferred instead, a small wcd9378-common
> stub dispatching on the property also works for me — your call.
> Either path can later sanity-check the fused mode the way the
> downstream driver does (EFUSE_REG_29 PLATFORM_BLOWN, else
> PLATFORM_CTL MODE) once register access is up.

We need single entry point, if not we will endup with two modalias. Yes
current RFC driver was only tested for compute.
I agree we should have a common so that we can leverage some code from
both modes.

> 
> One mobile-specific data point for the split: in mobile mode the SDCA
> control space is only decoded on the TX slave. On the FP6, a paged
> read of DEV_MANU_ID/DEV_PART_ID (0x40100060/0x40100068) via the TX
> slave returns 0x0217/0x0110, while the same reads via the RX slave
That is expected on WCD codecs. only TX has CSR registers space.
RX can not read/write any of the codec register space.
However the soundwire SCP address space is accessible and expected to
set data ports for both tx and rx.

> return zeros — with the RX slave's standard SCP DevID registers
> reading fine. That matches the downstream driver, which creates its
> only regmap on the TX device and drives the render dataports through
> the RX slave. So for mobile RX playback the function control and its
> dataports live on *different* slaves; a per-dataport slave mapping
> (or similar) would be needed in the class framework for that. Capture
> doesn't have this problem — the TX dataports sit on the control
> slave, so no cross-slave mapping is needed there.
> 
> 2) Bindings — one file
> 
> Patch 7 adds the same new file as my series
> (Documentation/devicetree/bindings/sound/qcom,wcd9378-sdw.yaml), so
> one of us should carry a merged version and the other drop it.
> Suggestion: the mobile side keeps my v1's tx/rx split shape, with
> the v2 changes already committed on my binding thread
> (qcom,{tx,rx}-port-mapping staying optional, matching
> qcom,wcd938x-sdw.yaml; qcom,{tx,rx}-channel-mapping dropped). The
> compute side keeps your qcom,compute-mode if/then, extended to also
> cover qcom,port-mapping and #sound-dai-cells. As posted, patch 7's mobile shape wouldn't
> validate my mobile DTS: it defines a combined qcom,port-mapping but
> the description references qcom,tx/rx-port-mapping, and
> #sound-dai-cells is required unconditionally while the mobile DAIs
> live on the top-level codec node. I'm happy to carry the merged file
> in my v2 so your v2 can drop patch 7 — or the reverse, whichever you
> prefer.
Thanks that would be nice, Also am thinking that we should just have
qcom,port-mapping for both modes and mark one of the device as
qcom,control-device which is tx in mobile case. That way we have some
level of clean bindings that overlap. But I will leave it up to you.


> 
> 3) Prototype findings on patches 1-6 (mobile capture, FP6)
> 
> What I ran: your 8 patches on my 7.1.2-based tree, plus a new
> wcd9378-sdca-mobile codec registering its own sdw_driver for the TX
> slave, static sdca_function_data for the SmartMic0 function
> (IT11 -> OT10 on DP1, with PDE11 as the power domain), and hw_ops
> doing the vendor bring-up
> (micbias routing, bus-clock indication, a clock-stop hold; supplies
> stay on the mobile top-level codec node, so hw_init has nothing to
> do — that part of the design accommodates the mobile supply model
> as-is). Capture works: the card binds, PDE11 reaches PS0 through the
> DAPM supply widget, and a 1 kHz tone played from the speakers
> captures at ~46% of full scale through the SDCA path. The bus-clock
> indication in hw_ops is partly a stopgap: the core path discussed
> with Pierre-Louis on my driver thread needs the qcom controller to
> set prop.mclk_freq, and that patch is still on my list. The
> prototype branch (your series + the mobile codec on a 7.1.2 base) is
> at https://forgejo.catcrafts.net/Catcrafts/milos-linux, branch
> sdca-mobile, if useful.
Yes, This is definitely an useful experiment, I was trying something
similar with both tx and rx side on mobile mode, things got really
complex because the sdw stream has to be handled by rx codec where as tx
side will be handled by sdca side.. it was really messy.

> 
> Findings:
> 
> a) PDM dataports. class_function_sdw_add_peripheral() derives the
>    SoundWire stream/port config from the host-visible PCM params via
>    snd_sdw_params_to_config(), but the WCD9378 mic dataports carry
>    1-bit PDM on a single channel (the working mobile driver programs
>    sconfig.bps = 1 and port ch_mask = BIT(0)). Result with the
>    generic path: "bps not matching" from the qcom master and silence
>    on the capture while the PDE sits happily in PS0. I prototyped
>    optional per-dataport overrides in sdca_entity_iot
>    (sdw_bps/sdw_ch_mask) consumed in add_peripheral, which fixed it;
>    maybe DisCo has a proper home for this, but something is needed
>    for PDM parts.
> 
> b) The IT33 micbias cache-vs-hardware workaround in your patch 8
>    (drop cache + rewrite from pde_pre_pmu) ported directly to the
>    mobile part's IT11; I carried it prophylactically and haven't yet
>    isolated whether mobile strictly needs it. If it does turn out to
>    be family behavior, it might argue for the class handling
>    has_default controls on PDE power-up generically.
> 
> Userspace needed no changes beyond UCM: the class-driver card works
> with a ControlExists conditional in the same profile (the stock
> branch of the conditional is the unchanged stock sequence).
> 
> On interrupts: sdca_irq_allocate() got a valid IRQ out of the box on
> my board via the bus irq domain; I haven't exercised actual SDCA
> interrupt delivery (capture doesn't need it), so I can't yet say
> whether the INTSTAT dispatch issue in your patch-8 comment reproduces
> here.
> 
> Longer term: until the framework covers mobile end-to-end (the PDM
> transport and the cross-slave RX question), my posted mobile series
> stays the working mobile path — the v2 above is about the two
> drivers coexisting cleanly in the meantime. Mobile capture converging
> on the class framework looks realistic (my static tables came
> straight from the posted mobile driver); I'll keep using the FP6 as
> the mobile-mode test vehicle for the next revisions.
> 

I think you should continue to do the mobile mode driver as it was done
in v1 not think about sdca. Function setup on mobile mode are dynamic
user can set sys_usage based on usecase so the sdca functions will
change, this is not static anymore so its not really worth thinking of
sdca for mobile atm, but we could try to see if we can get some leverage
from sdca helpers.

Sorry for the noise i hope it was a worth experiment on mobile mode.

> One dependency note for your platform posting: SDCA register access
> on Qualcomm controllers needs the SCP address paging support now in
> soundwire next, commit 999f80904763 ("soundwire: qcom: add SCP
> address paging support").
> 
> One small nit: link [2] in the cover credits "Jorijn Rikhof" — the
> surname is van der Graaf.

Am really Sorry not sure how I missed that.


--srini
> 
> Thanks,
> Jorijn