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

[thomas-soemoen]

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

1. 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)

2. sof-ptl-cs42l43-l2-cs35l56x6-l13.tplg from sof-bin v2025.05:
   Fails with EINVAL (-22) — targets different hardware layout

3. 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

[bardliao]

@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

[thomas-soemoen]

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.

[bardliao]

@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.

[charleskeepax]

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?

[charleskeepax]

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.

[bardliao]

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.

[charleskeepax]

@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.

[thomas-soemoen]

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?

[bardliao]

@thomas-soemoen Could you try #5773?

[thomas-soemoen]

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

[charleskeepax]

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.

[charleskeepax]

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

[thomas-soemoen]

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?

[bardliao]

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.