Re: [PATCH 0/7] ASoC: Intel: avs: Soundwire support

[Cezary Rojewski]

On 11/3/2026 6:37 AM, Vinod Koul wrote:
> On 02-11-26, 19:10, Cezary Rojewski wrote:
>> The RaptorLake-P and RaptorLake-M based platform used in Automotive area
>> do utilize SoundWire for streaming audio.  This patchset brings such
>> support to the public domain.
>>
>> If possible, I'd like the changes to go through Mark's tree.
>>
>> As the patchset updates drivers/soundwire, I've decided to strip it off
>> any machine-boards and have here just the changes done to the main
>> soundwire driver and their user/usage.  Machine boards for RPL-P/M will
>> follow in a separate set and do not touch drivers/soundwire stuff.
>>
>>
>> The reasoning behind modyfing the soundwire code:
>>
>> Typically dai->startup() is responsible for checking if all the required
>> resources are available whereas dai->hw_params() is responsible for
>> configuring such resources.  Existing code does the PDI assignment and
>> its configuration within one function - intel_hw_params().  The logical
>> split is not possible.  The change provides functions that represent
>> such logical blocks: assign, release and config.  Such division exists
>> already for the HDAudio interface, see sound/hda/core/stream.c
> 
> I understand that you want to split things up which helps your avs
> driver but I fail to understand why should we add one more layer in
> soundwire intel driver to handle one more driver from Intel.
> 
> Why not modify soundwire intel driver to do both startup and hw_params.
> This way the driver does not care if it is calling sof driver, avs
> driver or somenew team driver! I would like to avoid a new driver
> specific handling please..

The avs-driver does not predefine any resources, so that's the first
difference. Next, the avs-driver allocates all resources on startup()
and configures these only on hw_params(). Given the state of
intel_hw_params() function, I cannot say the same about the second driver.

I do agree that going forward, the existing intel_hw_params()/SOF code
could use an update. There are more benefits to the split than just "the
split" - the hooks in form of struct sdw_intel_ops e.g.: params_stream()
or free_stream() could be dropped.

However, I believe this should be done in a separate series - that's a
refactor and touches largely on the SOF code which I do not test in my
CI. For the refactor, I'd prefer to send such a patchset to
thesofproject GH first, and once their CI confirms come back here and
update the function.

Is such an approach OK with you, Vinod?