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

Hi Srini,

On Fri, 24 Jul 2026 13:17:06 +0100, Srinivas Kandagatla wrote:
> > 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.
> [...]
> 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.

Single entry point it is — that replaces the mirror check I had queued
above. My v2 will add the common stub instead: one sdw_driver owning
the 0x0217/0x0110 ID table, probe dispatching on the DT mode
properties (qcom,compute-mode -> compute, otherwise the mobile TX/RX
paths), with the compute branch returning -ENODEV until your driver
lands. Happy to shape the factoring to whatever slots into your v2
best, and shared code can accumulate in the common module as it shows
up.

> 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.

Thanks, good to have that confirmed.

> 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.

Let's use your shape. The merged file then has a single
qcom,port-mapping (still optional, as the wcd938x mappings are) on both
slave nodes, and qcom,control-device marking the TX slave in the
mobile presentation — the explicit flag takes over the TX/RX
discrimination that the split property names provided in my v1, and it
doubles as dispatch information for the common stub. Compute-only
requirements (#sound-dai-cells on the slave nodes, and whatever else
your v2 needs there) go behind if: qcom,compute-mode. I'll
carry the merged file in my v2 so your v2 can drop patch 7.

> 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.
> [...]
> 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.

No noise at all — it answered the RX-slave question and produced the
coexistence data above, so it paid for itself. Agreed on the
direction: mobile v2 stays the v1 approach, no SDCA; where a class
helper fits the mobile driver internals I'll borrow rather than
reinvent. I'll leave the sdca-mobile branch up, frozen at the RFC
state, for reference.

> Am really Sorry not sure how I missed that.

No worries.

So, concretely: my v2 carries the common entry point, the merged
binding as above, and the driver review items already queued from the
v1 thread; on your side patch 7 goes away and the compute probe hooks
into the stub. I'm spinning v2 next, so the merged binding will be
on the list for your v2 to reference.

Thanks,
Jorijn