Re: [PATCH 3/3] ASoC: codecs: wcd9378: add TX/capture codec driver

[Jorijn van der Graaf]

On Mon, 6 Jul 2026 22:41:48 +0100, Srinivas Kandagatla wrote:
> Thanks Jorijn for sending these patches over.
>
> Was there a reason why RX not added?

Only that the Fairphone 6 gives me no way to test it: the phone has
no headset jack (hence MBHC being left out too), and its earpiece is
one of the two Awinic speaker amps in receiver mode rather than the
codec's EAR output - so none of the codec's analog outputs appears
to drive anything on this board. TX/capture was the feature the
phone was missing, and I did not want to send RX code I cannot
exercise on hardware.

> I have been working on adding an SDCA compliant driver for this codec
> for Glymur compute laptops just few weeks back, not fully ready yet.
>
> @Ravi has been working on the same codec for a non compute device
> (Eliza) and has made some good progress.
>
> As this is an SDCA compliant codec, there might be way to get both modes
> working with single driver (either with or without generic drivers),
> which is something that I will be exploring in parallel.

That is very good news. Two findings from the FP6 bring-up that will
matter for the SDCA-mode work as well:

 - The SDCA function engine does not survive bus clock-stop (details
   in the commit message): registers keep their values, but the
   sequencers ignore every subsequent power request and only a codec
   reset revives them. The downstream stack works around it with
   "qcom,is-always-on" on the TX master. Whatever driver shape this
   ends up with will need a story for that.

 - Register accesses above the 15-bit direct space need SCP address
   paging in the qcom controller, which mainline does not implement;
   I posted "soundwire: qcom: add SCP address paging support"
   (20260706192150.143921-1-jorijnvdgraaf@xxxxxxxxxxxxx) alongside
   this series. The Glymur and Eliza drivers will need that too:
   all of the chip's codec control registers - SDCA functions and
   analog core alike - sit above the 15-bit direct space.

> Overall Looks like we could bring everything together to add better
> support for this codec.
>
> In the meantime Myself and Ravi will continue to test this codec along
> with other changes and get back

Sounds like a plan. I'll hold v2 for now so it can take a shape
that fits the single-driver direction; if the testing takes a while
I'll respin with the review fixes collected so far and we can
converge from there. The Fairphone 6 is a readily available retail
device, so consider it a standing test vehicle for the mobile
split-slave mode - happy to test patches on it.

Thanks,
Jorijn