linux-kernel - Re: [PATCH 0/5] ASoC/SOF/PCI/Intel: add Wildcat Lake support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e1005de-f5f8-4ad4-ad23-5fac81b24b33@linux.intel.com>
Date: Wed, 14 May 2025 16:09:30 +0300
From: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
 lgirdwood@...il.com, broonie@...nel.org
Cc: linux-sound@...r.kernel.org, kai.vehmanen@...ux.intel.com,
 ranjani.sridharan@...ux.intel.com, yung-chuan.liao@...ux.intel.com,
 guennadi.liakhovetski@...ux.intel.com, bhelgaas@...gle.com,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] ASoC/SOF/PCI/Intel: add Wildcat Lake support



On 14/05/2025 15:47, Pierre-Louis Bossart wrote:
> On 5/13/25 08:23, Péter Ujfalusi wrote:
>>
>>
>> On 12/05/2025 15:59, Pierre-Louis Bossart wrote:
>>>
>>>> The audio IP in Wildcat Lake (WCL) is largely identical to the one in
>>>> Panther Lake, the main difference is the number of DSP cores, memory
>>>> and clocking.
>>>> It is based on the same ACE3 architecture.
>>>>
>>>> In SOF the PTL topologies can be re-used for WCL to reduce duplication
>>>> of code and topology files. 
>>>
>>> Is this really true? I thought topology files are precisely the place where a specific pipeline is assigned to a specific core. If the number of cores is lower, then a PTL topology could fail when used on a WCL DSP, no?
>>
>> Yes, that is true, however for generic (sdw, HDA) topologies this is not
>> an issue as we don't spread the modules (there is no customization per
>> platform).
>> When it comes to product topologies, they can still be named as PTL/WCL
>> if needed and have tailored core use.
>>
>> It might be that WCL will not use audio configs common with PTL, in that
>> case we still can have sof-wcl-* topologies if desired.
> 
> Right, so the topologies can be used except when they cannot :-)

Right, topologies can be used when they are usable, if a new WCL only
config pops it's head then we can add it as sof-wcl-* or so-ptl-* if it
is expected to be present in PTL variants.

>> Fwiw, in case of soundwire we are moving to a even more generic function
>> topology split, where all SDW device can us generic function fragments
>> stitched together to create a complete topology.
>> Those will have to be compatible with all platforms, so wide swing of
>> core use cannot be possible anymore.
> 
> I couldn't follow this explanation, or I am missing some context. My expectation is that as soon as someone starts inserting a 3rd party module all bets on core assignment are off, I am not sure how rules could be generic without adding restrictions on where 3rd party modules are added.

As soon as anyone inserts 3rd party modules in topologies they will
create said topology for the machine they use and either select seaid
topology for the machine or use override to load that.

You cannot really add 3rd party modules to generic topologies since
somehow you need to make sure that the 3rd party module is somehow
available at the same time.

The difference regarding to audio in PTL to WCL is about the same as ARL
to ARL-S, yet with sof-arl-* topologies this somehow was not an issue
(and tgl and adl).

-- 
Péter