Re: [PATCH v3 7/7] ASoC: Intel: avs: SoundWire PCM BE operations

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 11/10/2026 9:02 AM, Pierre-Louis Bossart wrote:
> 
>>>> +
>>>> +	pdi = sdw_cdns_assign_pdi(codec->bus, dir);
>>>> +	if (!pdi) {
>>>> +		ret = -EBUSY;
>>>> +		goto err_assign_pdi;
>>>> +	}
>>>> +
>>>> +	/* Fulfill the codec needs by setting the sdw_stream. */
>>>> +	codec_dai = snd_soc_rtd_to_codec(rtd, 0);
>>>> +	snd_soc_dai_set_stream(codec_dai, sdw_stream, substream->stream);
>>>
>>> That absolutely does not scale to the case where you have multiple
>>> cpu_dais and multiple codec_dais.
>>>
>>> Please take a look at the sof_sdw machine driver (same solution used by
>>> AMD), and please use the sdw_utils library to deal with all the stream
>>> management.
>>
>>
>> I believe you are talking about aggregation.  No intention to support
>> that with this code.
>>
>> After reading the read I have an impression that the expectation of this
>> patchset is: full brown SoundWire support.  I wish I could agree with
>> you.  The reality is: standard PCM over codecs with and without SDCA.
>> If I get a user and an external release on top of that, I'll come back
>> and revisit.  The code present here provides simple implementation of
>> the goal, basically mirroring what's done for HDA in pcm.c nicely making
>> it easy to follow.
> well, I find it interesting that you are suggesting changes that impact
> existing to SoundWire *products* for what appears to be an experimental
> setup that will have to be changed *again* if and when there's a user.

The configurations are not experimental.  The base of this code exists
since 2021, shipping to upstream only now as the releases are external
only this year.  Is there a possibility for more configurations in the
future?  I guess the answer is yes.  Though I believe it's OK to change
stuff when the expectations/requirements change.

> It's ok to push background changes ahead of time to prepare the future.
> I am not sure what to think of your approach.
> 
> a) Mirroring HDaudio is not the goal, if that comes with a substandard
> way of using the SoundWire subsystem and capabilities does all this
> belong in the mainline? My take is that support for two amps is a
> standard feature, be they on the same link or not.
> b) At the very least you should have disclosed your goals, limitations
> of your approach, and be mindful of reviewer time.

You're correct, I should have listed the avs-pcm goals along the
reasoning behind the soundwire changes.  In regard to a), instead of
sending v4 today I'll try to integrate amp/aggregation and see the scale
of changes.  If it's wide-beyond the scope of this patchset, I'll opt
out.  If the changes are manageable, I'll update the series.

There is a benefit already of this iterative review - the first patch is
gone, the rest of them are not users of it and the code compiles just
fine without it - avs-driver brings in its own set of stubs in 5/7.

Thank you, Pierre!