include/linux/pci_ids.h | 1 + sound/hda/intel-dsp-config.c | 6 +++++- sound/pci/hda/hda_intel.c | 2 ++ sound/pci/hda/patch_hdmi.c | 1 + sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/pci-ptl.c | 30 ++++++++++++++++++++++++++++++ sound/soc/sof/intel/ptl.c | 23 +++++++++++++++++++++++ 7 files changed, 63 insertions(+), 1 deletion(-)
Hi, 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. Regards, Peter --- Kai Vehmanen (1): ALSA: hda: add HDMI codec ID for Intel WCL Peter Ujfalusi (4): PCI: pci_ids: add INTEL_HDA_WCL ASoC: SOF: Intel: add initial support for WCL ALSA: hda: intel-dsp-config: Add WCL support ALSA: hda: hda-intel: add Wildcat Lake support include/linux/pci_ids.h | 1 + sound/hda/intel-dsp-config.c | 6 +++++- sound/pci/hda/hda_intel.c | 2 ++ sound/pci/hda/patch_hdmi.c | 1 + sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/pci-ptl.c | 30 ++++++++++++++++++++++++++++++ sound/soc/sof/intel/ptl.c | 23 +++++++++++++++++++++++ 7 files changed, 63 insertions(+), 1 deletion(-) -- 2.49.0
> 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?
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. 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. -- Péter
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.
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
On 5/8/25 20:02, Peter Ujfalusi wrote: > Hi, > > 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. The thread clarified that the statement above is for generic topologies. Using specific cores and/or a 3rd party module will force topology editors to provide device-specific configurations. Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
© 2016 - 2026 Red Hat, Inc.