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.
