Missing sof-ptl-cs42l43-l3.tplg topology for ASUS ROG Zephyrus G16 GU606AP (Panther Lake + CS42L43 on link 3 + 2x CS35L56 on link 2)

System information

Machine: ASUS ROG Zephyrus G16 GU606AP
CPU: Intel Core Ultra 9 386H (Panther Lake)
Kernel: 6.17.0-22-generic (Ubuntu 24.04)
Audio PCI: Intel Corporation Device [8086:e328], subsystem [1043:1634]
firmware-sof-signed: 2023.12.1-1ubuntu1.10

Audio hardware (from dmesg)

Codec: Cirrus Logic CS42L43 (SoundWire link 3, sdw:0:3:01fa:4243:01)
Amplifiers: 2x Cirrus Logic CS35L56 Rev B0 (SoundWire link 2,
sdw:0:2:01fa:3556:01:0 and sdw:0:2:01fa:3556:01:1)
ACPI reports 3x SmartAmp functions (type 1) at device:37, :39, :3b
(2 physical CS35L56 + 1 virtual function inside CS42L43)

Problem

The kernel matches this machine against the ptl_cs42l43_l3 machine
table entry and expects the topology file:

intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3.tplg

This file does not exist in any released sof-bin version.

The kernel falls back to SDCA function topologies, but because ACPI
reports 3 SmartAmp functions, the kernel selects sof-sdca-1amp-id2.tplg
(the fallback) instead of sof-sdca-2amp-id2.tplg, resulting in only
one of the two physical amplifiers being active. Speaker output is thin
and low quality.

Attempted workarounds

sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg from sof-bin v2025.12.2:
Fails with topology ABI 3:29:1 vs kernel ABI 3:23:1 mismatch, and
widget type 27 (SSP BT dai-copier) not supported → EINVAL (-22)
sof-ptl-cs42l43-l2-cs35l56x6-l13.tplg from sof-bin v2025.05:
Fails with EINVAL (-22) — targets different hardware layout
disable_function_topology=1 module parameter: Allows monolithic
topology loading but all available files fail as described above.

What is needed

A topology file sof-ptl-cs42l43-l3.tplg targeting:

CS42L43 on SoundWire link 3
2x CS35L56 on SoundWire link 2
Compatible with kernel ABI 3:23:1 (Linux 6.17)
Without SSP BT widgets (widget type 27)

Alternatively, a fix to the SDCA function topology selection logic so
that 2 physical CS35L56 amplifiers are correctly detected despite ACPI
reporting 3 SmartAmp functions.

Relevant dmesg

[ 5.341272] acpi device:37: find_sdca_function: SDCA function SmartAmp (type 1) at 0x1
[ 5.341339] acpi device:39: find_sdca_function: SDCA function SmartAmp (type 1) at 0x1
[ 5.341449] acpi device:3b: find_sdca_function: SDCA function SmartAmp (type 1) at 0x1
[ 5.353319] sof-audio-pci-intel-ptl 0000:00:1f.3: Topology file: intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3.tplg
[ 5.520704] sof-audio-pci-intel-ptl 0000:00:1f.3: Using function topologies instead intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3.tplg
[ 5.520970] sof-audio-pci-intel-ptl 0000:00:1f.3: loading topology 2: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg

@thomas-soemoen

@thomas-soemoen Could you try #5728? In theory, it will not match the ptl_cs42l43_l3 machine and use the function topologies instead. The driver will generate a mach table according to the ACPI table.
https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/intel/hda.c#L1420
So, in theory, it will use sof-sdca-2amp-id2.tplg

Thanks for the pointer to #5728!

I actually managed to get audio working by taking a different approach — instead of avoiding the ptl_cs42l43_l3 match, I added a correct machine entry with the right link_mask and supporting changes across four modules.

Here is a summary of what I changed:

1. sound/soc/sof/intel/hda.c
Moved chip = get_chip_info() earlier and added a partial SDW machine match check for ACE 2.0+, avoiding incorrect topology selection (similar to the #5728 approach but from the machine-match side).

2. sound/soc/intel/common/soc-acpi-intel-ptl-match.c
Added a new cs35l56_2_2amp_adr[] with ADRs 0x00023001fa355601 and 0x00023101fa355601, a new ptl_cs42l43_l3_cs35l56_l2[] link definition, and a new machine entry with link_mask = BIT(2)|BIT(3) and get_function_tplg_files = sof_sdw_get_tplg_files.

3. sound/soc/intel/boards/sof_sdw.c and sound/soc/sdw_utils/soc_sdw_utils.c
Added a DMI entry for ASUS ROG Zephyrus G16 GU606AP with quirk SOC_SDW_SIDECAR_AMPS | SOC_SDW_SDW_AMPS. Changed CS42L43 dp6 from quirk = SOC_SDW_CODEC_SPKR | SOC_SDW_SIDECAR_AMPS to quirk = SOC_SDW_SIDECAR_AMPS, quirk_exclude = true to avoid SPI bridge link.

4. sound/soc/sdw_utils/snd-soc-sdw-utils.ko
Added #define SOC_SDW_SDW_AMPS BIT(19) and updated count_sidecar, add_sidecar and spk_init to check !(ctx->mc_quirk & SOC_SDW_SDW_AMPS) to avoid SPI bridge link.

Topology symlink:

/lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
→ sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg

Tested on kernel 6.17.0-23-generic (Ubuntu 24.04). Both speakers are now active and audio works correctly via sof-soundwire, device 2: Speaker.

Note: I used Claude (Anthropic) as a guide throughout the debugging and patching process, and for writing this comment, since I am not versed in this.

@thomas-soemoen

@thomas-soemoen Thanks for the effort. The changes sound reasonable. Do you mind sharing those changes? We could discuss which way is better. Our direction is not adding new ADRs to soc-acpi-intel-ptl-match.c. I would like to revert the change 2 if possible. And regarding the DMI quirks, I think what you need to do is to modify the DMI quirk in sound/soc/intel/boards/sof_sdw.c instead of changing the quirk in sound/soc/sdw_utils/soc_sdw_utils.c.
BTW, you can use options snd_soc_sof_sdw quirk= to set the cs42l43 dp6 quick value.

Yeah ideally we want to avoid continually adding new match tables so it would be better to work out why the function topologies are not working in this case. Is the problem here we are seeing bad interaction between dissimilar aggregated speakers and
function topologies?

Ah wait, is the correct fix here just to remove the match table entry we do have on ptl? Like that shouldn't be necessary as function topologies should be able to cover everything.

Ah wait, is the correct fix here just to remove the match table entry we do have on ptl? Like that shouldn't be necessary as function topologies should be able to cover everything.

If there is no ghost codec in the ACPI table and with #5728 , yes, I think function topology should be able to cover everything.

@thomas-soemoen

@thomas-soemoen If possible if you could revert your current fixes and then also revert the change:

dfbb57c ("ASoC: Intel: soc-acpi-ptl-match: add cs42l43_agg_l3_cs35l56_2 support")

And let us know if everything works after that. We will need to decide how we resolve that match table but at least this will double check that this is the only issue we need to solve.

I have reverted my previous fixes and attempted to test #5728.

I fetched only sound/soc/sof/intel/hda.c from the PR branch and tried to build it against my running kernel (6.17.0-23-generic, Ubuntu 24.04), but got a compilation error:

In file included from hda-stream.c:22:
../ops.h: In function 'snd_sof_load_firmware':
../ops.h:22:29: error: too few arguments to function '((const struct snd_sof_dsp_ops *)sdev->pdata->desc->ops)->load_firmware'
make: *** [Makefile:248: __sub-make] Error 2

It looks like the PR branch is based on a newer codebase than my kernel headers, so the load_firmware function signature has changed and the file is not compatible as-is.

As expected, with my fixes reverted and #5728 not buildable, audio is no longer working.

Could you advise on the best way to test #5728 against 6.17.0-23-generic? Or alternatively, is there a simpler patch I could apply manually?

@thomas-soemoen

@thomas-soemoen Could you try #5773?

@thomas-soemoen Could you try #5773?

I tried testing #5773 but ran into the same compilation error as with #5728:

In file included from hda-stream.c:22:
../ops.h: In function 'snd_sof_load_firmware':
../ops.h:22:29: error: too few arguments to function '((const struct snd_sof_dsp_ops *)sdev->pdata->desc->ops)->load_firmware'
make: *** [Makefile:248: __sub-make] Error 2

The issue seems to be that both PRs are based on a newer SOF branch where the load_firmware function signature has changed, making it incompatible with the kernel headers in 6.17.0-23-generic (Ubuntu 24.04).

I have reverted to my own working fix in the meantime. Would it be possible to provide a backported patch that applies cleanly against 6.17.0-23-generic?

I have just updated the chain with an extra patch and I believe the middle patch in that will fix this issue ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional

This laptop appears to share a device layout that perfectly overlaps with a Chromebook that requires a custom topology and thus it doesn't use the function topologies like it should. I think this patch will cherry pick relatively cleanly to 6.17 (assuming this match has been backported and that is indeed the problem), but it would be better to test on a mainline kernel if that is possible for you.

Ubuntu doesn't exactly make their source user-friendly but I would say you have about an 80% chance this is based on Ubuntu's 6.17.

0001-ASoC-soc-acpi-intel-ptl-match-Make-Chrome-matches-co.patch

Good news — the patch applies cleanly against 6.17.0-23-generic (with an offset of 36 lines) and audio is working after installing the new modules.

However, I noticed that the patch alone is not sufficient. Audio only works if the following symlink is also in place:

/lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
→ /lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg

When I removed the symlink and rebooted, audio stopped working. Restoring the symlink and rebooting brought audio back.

This suggests that the topology file sof-ptl-cs42l43-l3-cs35l56-l2.tplg is either missing or not being loaded correctly without the symlink. Is this expected, or is there an additional fix needed for the topology side?

Good news — the patch applies cleanly against 6.17.0-23-generic (with an offset of 36 lines) and audio is working after installing the new modules.

However, I noticed that the patch alone is not sufficient. Audio only works if the following symlink is also in place:
/lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
→ /lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg
When I removed the symlink and rebooted, audio stopped working. Restoring the symlink and rebooting brought audio back.

This suggests that the topology file sof-ptl-cs42l43-l3-cs35l56-l2.tplg is either missing or not being loaded correctly without the symlink. Is this expected, or is there an additional fix needed for the topology side?

Can you share the dmesg log? In theory, you don't need any of those tplg file.

Yeah that patch should make it so that match no longer applies on the laptop. Agree with Bard dmesg is a good start but double check you are running the right kernel.

Here is the dmesg output with the patch applied on 6.17.0-23-generic:

[    4.200661] snd_soc_acpi_intel_sdca_quirks: module verification failed: signature and/or required key missing - tainting kernel
[    4.238419] sof-audio-pci-intel-ptl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[    5.782353] sof-audio-pci-intel-ptl 0000:00:1f.3:  Topology file:     intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
[    6.001872] sof_sdw sof_sdw: Found 3 devices with 6 endpoints
[    6.001880] sof_sdw sof_sdw: Adding prefix AMP1 for sdw:0:2:01fa:3556:01:0
[    6.001885] sof_sdw sof_sdw: Adding prefix AMP2 for sdw:0:2:01fa:3556:01:1
[    6.001888] sof_sdw sof_sdw: Adding prefix cs42l43 for cs42l43-codec
[    6.005385] sof-audio-pci-intel-ptl 0000:00:1f.3: Using function topologies instead intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
[    6.005389] sof-audio-pci-intel-ptl 0000:00:1f.3: loading topology 0: intel/sof-ipc4-tplg/sof-sdca-1amp-id2.tplg
[    6.005419] sof-audio-pci-intel-ptl 0000:00:1f.3: loading topology 1: intel/sof-ipc4-tplg/sof-sdca-jack-id0.tplg
[    6.005670] sof-audio-pci-intel-ptl 0000:00:1f.3: loading topology 2: intel/sof-ipc4-tplg/sof-sdca-mic-id4.tplg
[    6.005747] sof-audio-pci-intel-ptl 0000:00:1f.3: loading topology 3: intel/sof-ipc4-tplg/sof-hdmi-pcm5-id5.tplg
[    6.067976] cs35l56 sdw:0:2:01fa:3556:01:0: Calibration disabled due to missing firmware controls
[    6.069121] cs35l56 sdw:0:2:01fa:3556:01:0: Can't read tuning IDs
[    6.075621] cs35l56 sdw:0:2:01fa:3556:01:1: Calibration disabled due to missing firmware controls
[    6.076452] cs35l56 sdw:0:2:01fa:3556:01:1: Can't read tuning IDs

The patch is working — the system is now using function topologies instead of the static match. However, I notice it is loading sof-sdca-1amp-id2.tplg even though the system has two CS35L56 amplifiers (AMP1 and AMP2). I would have expected sof-sdca-2amp-id2.tplg.

Also, audio only works if the following symlink is present:

/lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-l3-cs35l56-l2.tplg
→ /lib/firmware/intel/sof-ipc4-tplg/sof-ptl-cs42l43-agg-l3-cs35l56-l2.tplg

Without it, audio does not work after reboot. Is this symlink still needed, or does it indicate something else is wrong?

@thomas-soemoen

@thomas-soemoen It is likely sof-ptl-cs42l43-l3-cs35l56-l2.tplg is set in your sound/soc/intel/common/soc-acpi-intel-ptl-match.c. And I can't find it from the upstream kernel. Can you share your sound/soc/intel/common/soc-acpi-intel-ptl-match.c?

Here is the relevant section of my soc-acpi-intel-ptl-match.c. I can see there is an entry that does not appear to be in upstream:

{
    .link_mask = BIT(2) | BIT(3),
    .links = ptl_cs42l43_l3_cs35l56_l2,
    .drv_name = "sof_sdw",
    .sof_tplg_filename = "sof-ptl-cs42l43-l3-cs35l56-l2.tplg",
    .get_function_tplg_files = sof_sdw_get_tplg_files,
},

This entry matches my hardware (CS42L43 on link 3, CS35L56 x2 on link 2) and is the reason the symlink is needed — it references sof-ptl-cs42l43-l3-cs35l56-l2.tplg which does not exist without the symlink. This appears to be the Ubuntu-specific commit dfbb57c you mentioned earlier.

So to summarize the current situation:

Your patch correctly prevents the Chrome-only match from applying to my laptop
But this Ubuntu-specific entry then matches instead, requiring the symlink
Without the symlink, audio does not work

Would the correct fix be to also add a machine_check = snd_soc_acpi_intel_no_function_topology to this entry, similar to what your patch does for the ptl_cs42l43_l3 entry?

@charleskeepax

Here is the relevant section of my soc-acpi-intel-ptl-match.c. I can see there is an entry that does not appear to be in upstream:

{
.link_mask = BIT(2) | BIT(3),
.links = ptl_cs42l43_l3_cs35l56_l2,
.drv_name = "sof_sdw",
.sof_tplg_filename = "sof-ptl-cs42l43-l3-cs35l56-l2.tplg",
.get_function_tplg_files = sof_sdw_get_tplg_files,
},
This entry matches my hardware (CS42L43 on link 3, CS35L56 x2 on link 2) and is the reason the symlink is needed — it references sof-ptl-cs42l43-l3-cs35l56-l2.tplg which does not exist without the symlink. This appears to be the Ubuntu-specific commit dfbb57c you mentioned earlier.

So to summarize the current situation:

Your patch correctly prevents the Chrome-only match from applying to my laptop

But this Ubuntu-specific entry then matches instead, requiring the symlink

Without the symlink, audio does not work

Would the correct fix be to also add a machine_check = snd_soc_acpi_intel_no_function_topology to this entry, similar to what your patch does for the ptl_cs42l43_l3 entry?

I will let @charleskeepax to comment. Either add a machine_check = snd_soc_acpi_intel_no_function_topology or remove it completely depends on is there any Google device need the entry.

Makes most sense just to remove it to me, not sure why Ubuntu added it.

I believe everything necessary for this laptop should be upstream please re-open/file a new issue if there are still problems.

Navigation Menu

Repository navigation

Missing sof-ptl-cs42l43-l3.tplg topology for ASUS ROG Zephyrus G16 GU606AP (Panther Lake + CS42L43 on link 3 + 2x CS35L56 on link 2) #5759

System information

Audio hardware (from dmesg)

Problem

Attempted workarounds

What is needed

Relevant dmesg

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Missing sof-ptl-cs42l43-l3.tplg topology for ASUS ROG Zephyrus G16 GU606AP (Panther Lake + CS42L43 on link 3 + 2x CS35L56 on link 2) #5759

Description

System information

Audio hardware (from dmesg)

Problem

Attempted workarounds

What is needed

Relevant dmesg

Activity

bardliao commented on May 5, 2026

thomas-soemoen commented on May 6, 2026

bardliao commented on May 7, 2026

charleskeepax commented on May 7, 2026

charleskeepax commented on May 7, 2026

bardliao commented on May 7, 2026

charleskeepax commented on May 12, 2026

thomas-soemoen commented on May 14, 2026

bardliao commented on May 14, 2026

thomas-soemoen commented on May 14, 2026

charleskeepax commented on May 14, 2026

charleskeepax commented on May 14, 2026

thomas-soemoen commented on May 16, 2026

bardliao commented on May 19, 2026

charleskeepax commented on May 19, 2026

thomas-soemoen commented on May 19, 2026

bardliao commented on May 20, 2026

thomas-soemoen commented on May 21, 2026

bardliao commented on May 22, 2026

charleskeepax commented on May 22, 2026

charleskeepax commented on Jul 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions