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

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 7/13/26 09:28, Srinivas Kandagatla wrote:
> 
> On 7/7/26 12:42 PM, Pierre-Louis Bossart wrote:
>>> + *
>>> + * Qualcomm WCD9378 audio codec driver.
>>> + *
>>> + * The WCD9378 pairs a WCD937x-compatible analog core with SDCA-style
>> SDCA-style or SDCA-compliant?
> 
> This codec is SDCA compliant and used on X2 Elite Windows laptops.
> 
> This Codec can be configured in two modes, Mobile and Compute, and this
> configuration is fused out.

How would you the drivers know which configuration is used? read from platform firmware?

> The codec IP is the same in both modes; what changes is how the
> host-side SoundWire master setup.
> 
> The codec itself has two modes of working.
> 1. mobile mode
> 	in this mode the codec is enumerated as two slaves(tx and rx) on two
> different soundwire masters (tx and rx), like any other wcd codecs.
> 
> 2. compute mode
> 	In this mode, where the codec is enumerated as single slave on primary
> soundwire master. Two Soundwire controllers(primary and dependent i.e tx
> and rx) are aggregated and they act as one logical SoundWire bus with
> four data lanes. The primary alone runs the SCP control channel,
> enumerates the slave, drives the bus clock, the secondary follows. The
> secondary drives some of the data lanes. There is a hardware sync
> between these two. This is a new configuration on Qualcomm Soundwire
> controllers called multi-master.

Very useful explanation, thanks.

In this configuration, I guess each lane is really dedicated to specific traffic?
In theory the LaneCtrl port register allows a stream to be dynamically moved to a different lane, but I am not sure how this would work in such a 'multi-master' implementation. Along the same lines, I'd guess the non-zero data lanes remain enabled while the clock toggles, even if there's no traffic?

Management and optimization of multi-lane systems isn't straightforward, I've heard two theories:
- one where it's better to only enable multi-lane when the bandwidth on lane0 is exceeded.
- and a second where it's better to spread traffic on separate lanes and lower the clock.
It probably depends on a number of factors, and in the end on how codecs are wired to the different lanes...

> From Codec pov, its exactly same IP, I have now SDCA drivers working for
> both playback and capture, so Am hoping that we could use the same SDCA
> driver for both of these modes. I still have to give it a try on a
> mobile platform to verify this.
> 
> Am hoping to send a version of this driver sometime this week.

Sounds good.