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>] [day] [month] [year] [list]

Message-ID: <e7032baf-2742-450a-ab3d-5cb34bd22152@linux.intel.com>
Date: Tue, 13 May 2025 13:18:28 +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 13/05/2025 09:21, 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.
> 
> 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

My line of thinking was:
sof-tgl topologies: TGL (4 cores), TGL-H (2 cores)
sof-adl topologies: ADL/ADL-N (4 cores), ADL-S (2 cores)
sof-arl topologies: ARL (3 cores), ARL-S (2 cores)

the PTL vs WCL is not much of a difference apart from the fact that the
produce code-name is not a postfixed one:
sof-ptl topologies: PTL (5 cores), WCL (3 cores)

-- 
Péter