[PATCH 0/5] ASoC/SOF/PCI/Intel: add Wildcat Lake support

[PATCH 0/5] ASoC/SOF/PCI/Intel: add Wildcat Lake support

[Peter Ujfalusi]

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

[PATCH 1/5] PCI: pci_ids: add INTEL_HDA_WCL

[Peter Ujfalusi]

Add PCI id for Wildcat Lake audio.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
---
 include/linux/pci_ids.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 981ed45cc45e..e2d71b6fdd84 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -3049,6 +3049,7 @@
 #define PCI_DEVICE_ID_INTEL_HDA_DG1	0x490d
 #define PCI_DEVICE_ID_INTEL_HDA_EHL_0	0x4b55
 #define PCI_DEVICE_ID_INTEL_HDA_EHL_3	0x4b58
+#define PCI_DEVICE_ID_INTEL_HDA_WCL	0x4d28
 #define PCI_DEVICE_ID_INTEL_HDA_JSL_N	0x4dc8
 #define PCI_DEVICE_ID_INTEL_HDA_DG2_0	0x4f90
 #define PCI_DEVICE_ID_INTEL_HDA_DG2_1	0x4f91
-- 
2.49.0

Re: [PATCH 1/5] PCI: pci_ids: add INTEL_HDA_WCL

[Krzysztof Wilczyński]

Hello,

Just a few small nitpicks.

Consider an update to the subject to match the history, e.g.,

  PCI: Add Intel Wildcat Lake audio Device ID

> Add PCI id for Wildcat Lake audio.

Also, for consistency with other such commits:

  Add Wildcat Lake (WCL) audio Device ID.

> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

Acked-by: Krzysztof Wilczyński <kwilczynski@kernel.org>

Thank you!

	Krzysztof

Re: [PATCH 1/5] PCI: pci_ids: add INTEL_HDA_WCL

[Péter Ujfalusi]

On 15/05/2025 20:03, Krzysztof Wilczyński wrote:
> Hello,
> 
> Just a few small nitpicks.
> 
> Consider an update to the subject to match the history, e.g.,
> 
>   PCI: Add Intel Wildcat Lake audio Device ID

I have looked up the history and used the previous audio IP ID addition
commit as template:

a1f7b7ff0e10 ("PCI: pci_ids: add INTEL_HDA_PTL_H")

PCI: pci_ids: add INTEL_HDA_PTL_H

Add Intel PTL-H audio Device ID.

I will update and stick with the suggested suggestion for the future.
>> Add PCI id for Wildcat Lake audio.
> 
> Also, for consistency with other such commits:
> 
>   Add Wildcat Lake (WCL) audio Device ID.
> 
>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
>> Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
>> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
>> Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
>> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> 
> Acked-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
> 
> Thank you!
> 
> 	Krzysztof

-- 
Péter

[PATCH 2/5] ALSA: hda: add HDMI codec ID for Intel WCL

[Peter Ujfalusi]

From: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Add HDMI codec ID for Intel Wildcat Lake platform.

Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
---
 sound/pci/hda/patch_hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index a3a53e63a51a..f451b9a671c0 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -4651,6 +4651,7 @@ HDA_CODEC_ENTRY(0x8086281e, "Battlemage HDMI",	patch_i915_adlp_hdmi),
 HDA_CODEC_ENTRY(0x8086281f, "Raptor Lake P HDMI",	patch_i915_adlp_hdmi),
 HDA_CODEC_ENTRY(0x80862820, "Lunar Lake HDMI",	patch_i915_adlp_hdmi),
 HDA_CODEC_ENTRY(0x80862822, "Panther Lake HDMI",	patch_i915_adlp_hdmi),
+HDA_CODEC_ENTRY(0x80862823, "Wildcat Lake HDMI",	patch_i915_adlp_hdmi),
 HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI",	patch_generic_hdmi),
 HDA_CODEC_ENTRY(0x80862882, "Valleyview2 HDMI",	patch_i915_byt_hdmi),
 HDA_CODEC_ENTRY(0x80862883, "Braswell HDMI",	patch_i915_byt_hdmi),
-- 
2.49.0

[PATCH 3/5] ASoC: SOF: Intel: add initial support for WCL

[Peter Ujfalusi]

Clone PTL and adjust the number of cores from 5 to 3.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
---
 sound/soc/sof/intel/hda.h     |  1 +
 sound/soc/sof/intel/pci-ptl.c | 30 ++++++++++++++++++++++++++++++
 sound/soc/sof/intel/ptl.c     | 23 +++++++++++++++++++++++
 3 files changed, 54 insertions(+)

diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h
index 108cad04879e..e14f82c0831f 100644
--- a/sound/soc/sof/intel/hda.h
+++ b/sound/soc/sof/intel/hda.h
@@ -935,6 +935,7 @@ extern const struct sof_intel_dsp_desc mtl_chip_info;
 extern const struct sof_intel_dsp_desc arl_s_chip_info;
 extern const struct sof_intel_dsp_desc lnl_chip_info;
 extern const struct sof_intel_dsp_desc ptl_chip_info;
+extern const struct sof_intel_dsp_desc wcl_chip_info;
 
 /* Probes support */
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_PROBES)
diff --git a/sound/soc/sof/intel/pci-ptl.c b/sound/soc/sof/intel/pci-ptl.c
index 7d4c46f56931..68f6a9841633 100644
--- a/sound/soc/sof/intel/pci-ptl.c
+++ b/sound/soc/sof/intel/pci-ptl.c
@@ -55,10 +55,40 @@ static const struct sof_dev_desc ptl_desc = {
 	.ops_init = sof_ptl_ops_init,
 };
 
+static const struct sof_dev_desc wcl_desc = {
+	.use_acpi_target_states	= true,
+	.machines               = snd_soc_acpi_intel_ptl_machines,
+	.alt_machines		= snd_soc_acpi_intel_ptl_sdw_machines,
+	.resindex_lpe_base      = 0,
+	.resindex_pcicfg_base   = -1,
+	.resindex_imr_base      = -1,
+	.irqindex_host_ipc      = -1,
+	.chip_info		= &wcl_chip_info,
+	.ipc_supported_mask	= BIT(SOF_IPC_TYPE_4),
+	.ipc_default		= SOF_IPC_TYPE_4,
+	.dspless_mode_supported	= true,
+	.default_fw_path = {
+		[SOF_IPC_TYPE_4] = "intel/sof-ipc4/wcl",
+	},
+	.default_lib_path = {
+		[SOF_IPC_TYPE_4] = "intel/sof-ipc4-lib/wcl",
+	},
+	.default_tplg_path = {
+		[SOF_IPC_TYPE_4] = "intel/sof-ipc4-tplg",
+	},
+	.default_fw_filename = {
+		[SOF_IPC_TYPE_4] = "sof-wcl.ri",
+	},
+	.nocodec_tplg_filename = "sof-ptl-nocodec.tplg",
+	.ops = &sof_ptl_ops,
+	.ops_init = sof_ptl_ops_init,
+};
+
 /* PCI IDs */
 static const struct pci_device_id sof_pci_ids[] = {
 	{ PCI_DEVICE_DATA(INTEL, HDA_PTL, &ptl_desc) }, /* PTL */
 	{ PCI_DEVICE_DATA(INTEL, HDA_PTL_H, &ptl_desc) }, /* PTL-H */
+	{ PCI_DEVICE_DATA(INTEL, HDA_WCL, &wcl_desc) }, /* WCL */
 	{ 0, }
 };
 MODULE_DEVICE_TABLE(pci, sof_pci_ids);
diff --git a/sound/soc/sof/intel/ptl.c b/sound/soc/sof/intel/ptl.c
index aa0b772178bc..875d18193b05 100644
--- a/sound/soc/sof/intel/ptl.c
+++ b/sound/soc/sof/intel/ptl.c
@@ -126,6 +126,29 @@ const struct sof_intel_dsp_desc ptl_chip_info = {
 	.hw_ip_version = SOF_INTEL_ACE_3_0,
 };
 
+const struct sof_intel_dsp_desc wcl_chip_info = {
+	.cores_num = 3,
+	.init_core_mask = BIT(0),
+	.host_managed_cores_mask = BIT(0),
+	.ipc_req = MTL_DSP_REG_HFIPCXIDR,
+	.ipc_req_mask = MTL_DSP_REG_HFIPCXIDR_BUSY,
+	.ipc_ack = MTL_DSP_REG_HFIPCXIDA,
+	.ipc_ack_mask = MTL_DSP_REG_HFIPCXIDA_DONE,
+	.ipc_ctl = MTL_DSP_REG_HFIPCXCTL,
+	.rom_status_reg = LNL_DSP_REG_HFDSC,
+	.rom_init_timeout = 300,
+	.ssp_count = MTL_SSP_COUNT,
+	.d0i3_offset = MTL_HDA_VS_D0I3C,
+	.read_sdw_lcount =  hda_sdw_check_lcount_ext,
+	.check_sdw_irq = lnl_dsp_check_sdw_irq,
+	.check_sdw_wakeen_irq = lnl_sdw_check_wakeen_irq,
+	.check_ipc_irq = mtl_dsp_check_ipc_irq,
+	.cl_init = mtl_dsp_cl_init,
+	.power_down_dsp = mtl_power_down_dsp,
+	.disable_interrupts = lnl_dsp_disable_interrupts,
+	.hw_ip_version = SOF_INTEL_ACE_3_0,
+};
+
 MODULE_IMPORT_NS("SND_SOC_SOF_INTEL_MTL");
 MODULE_IMPORT_NS("SND_SOC_SOF_INTEL_LNL");
 MODULE_IMPORT_NS("SND_SOC_SOF_HDA_MLINK");
-- 
2.49.0

Re: [PATCH 3/5] ASoC: SOF: Intel: add initial support for WCL

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 163 bytes --]

On Thu, May 08, 2025 at 09:02:38PM +0300, Peter Ujfalusi wrote:
> Clone PTL and adjust the number of cores from 5 to 3.

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH 4/5] ALSA: hda: intel-dsp-config: Add WCL support

[Peter Ujfalusi]

WCL uses the same receipt as PTL and PTL-H

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
---
 sound/hda/intel-dsp-config.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/hda/intel-dsp-config.c b/sound/hda/intel-dsp-config.c
index 01594f858129..3cb1e7fc3b3b 100644
--- a/sound/hda/intel-dsp-config.c
+++ b/sound/hda/intel-dsp-config.c
@@ -541,7 +541,7 @@ static const struct config_entry config_table[] = {
 	},
 #endif
 
-	/* Panther Lake */
+	/* Panther Lake, Wildcat Lake */
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_PANTHERLAKE)
 	{
 		.flags = FLAG_SOF | FLAG_SOF_ONLY_IF_DMIC_OR_SOUNDWIRE,
@@ -551,6 +551,10 @@ static const struct config_entry config_table[] = {
 		.flags = FLAG_SOF | FLAG_SOF_ONLY_IF_DMIC_OR_SOUNDWIRE,
 		.device = PCI_DEVICE_ID_INTEL_HDA_PTL_H,
 	},
+	{
+		.flags = FLAG_SOF | FLAG_SOF_ONLY_IF_DMIC_OR_SOUNDWIRE,
+		.device = PCI_DEVICE_ID_INTEL_HDA_WCL,
+	},
 
 #endif
 
-- 
2.49.0

[PATCH 5/5] ALSA: hda: hda-intel: add Wildcat Lake support

[Peter Ujfalusi]

One more PCI ID.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
---
 sound/pci/hda/hda_intel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index d7651a75c629..e6df706f740d 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2549,6 +2549,8 @@ static const struct pci_device_id azx_ids[] = {
 	{ PCI_DEVICE_DATA(INTEL, HDA_PTL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) },
 	/* Panther Lake-H */
 	{ PCI_DEVICE_DATA(INTEL, HDA_PTL_H, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) },
+	/* Wildcat Lake */
+	{ PCI_DEVICE_DATA(INTEL, HDA_WCL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_LNL) },
 	/* Apollolake (Broxton-P) */
 	{ PCI_DEVICE_DATA(INTEL, HDA_APL, AZX_DRIVER_SKL | AZX_DCAPS_INTEL_BROXTON) },
 	/* Gemini-Lake */
-- 
2.49.0

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

[Pierre-Louis Bossart]

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

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

[Péter Ujfalusi]

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

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

[Pierre-Louis Bossart]

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.

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

[Péter Ujfalusi]

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

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

[Péter Ujfalusi]

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

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

[Pierre-Louis Bossart]

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>