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

[Srinivas Kandagatla]

On 7/13/26 9:16 AM, Pierre-Louis Bossart wrote:
> 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?
We can read fuse registers to get this info. this is pretty much fixed
for each SoC, so the device tree description would also have to reflect
that topology.
> 
>> 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?
Exactly, on X2 Elite lane 0 and 1 are for TX traffic and Lane 2 and Lane
3 are for RX 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?
This is pretty much fixed, frame shapping and lane mapping is hardcoded
in device tree.

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

This is case is pretty much fixed due to how the lanes are wiredup
internally.

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