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: <7f3b2d28-38d0-482c-b79a-5aabed6b6ea8@linux.dev>
Date: Wed, 14 May 2025 14:47:21 +0200
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>
To: Péter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
 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 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 :-)

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