linux-ptl: add Lenovo 83QK SOF SoundWire audio quirk

[itisyb]

Summary

Fixes built-in speakers and internal microphone on Lenovo Yoga Slim 7 Ultra 14IPH11 (83QK, PCI audio subsystem 17aa:3821) for linux-ptl.

This machine has:

• CS42L43 on SoundWire link 3
• RT722/ALC722 also described on link 3, but it stays UNATTACHED
• CS35L57/CS35L56 speaker amps on SPI sidecar
• internal microphone working through the PCH DMIC path in the -2ch topology

The fix keeps the ghost RT722 only for matching, routes speakers through the CS42L43 + CS35L56 sidecar path, selects the shipped -2ch topology, skips the silent CS42L43 SoundWire mic endpoint, and uses topology-provided NHLT blobs for the PCH DMIC.

What was broken

Before these patches, speaker playback could be routed through the unattached RT722 path and failed with errors like:

rt722-sdca ... DPN_PortCtrl register write failed
soundwire ... Program transport params failed: -61
SDW3-Playback-SmartAmp: ASoC error (-61)

The first speaker fix worked, but the internal microphone was still wrong. The usable mic path is the PCH DMIC from:

sof-arl-cs42l43-l2-cs35l56-l3-2ch.tplg

The BIOS NHLT lookup did not provide a matching blob for that PCH DMIC path; using topology-provided NHLT blobs fixed capture.

Patch contents

• 0030-sof-intel-exact-sdw-mask.patch

  • Requires exact SoundWire link-mask matching on ACE2+ platforms.

• 0031-ptl-mach-lenovo-83qk-rt722-ghost.patch

  • Adds the Lenovo 83QK machine entry.
  • Keeps RT722/ALC722 as a zero-endpoint ghost so matching succeeds but audio is not routed through it.

• 0032-sdw-utils-lenovo-83qk-skip-cs42l43-sdca-check.patch

  • Avoids skipping needed CS42L43 endpoints on this sidecar-amp layout.

• 0033-lenovo-83qk-force-2ch-pch-dmic.patch

  • Clamps 17aa:3821 from 4 reported DMICs to 2 so the shipped -2ch topology is selected.

• 0034-lenovo-83qk-exclude-cs42l43-sdw-dmic.patch

  • Marks 17aa:3821 with SOC_SDW_CODEC_MIC so the CS42L43 SoundWire mic endpoint is skipped.
  • This lets the PCH dmic01 link line up with the topology.

• 0035-lenovo-83qk-use-topology-nhlt-for-pch-dmic.patch

  • For 17aa:3821, uses topology-provided NHLT blobs instead of BIOS NHLT for the PCH DMIC.
  • This fixes the previous no matching blob ... DMIC Raw capture failure.

Tested result

Validated locally with:

linux-ptl 7.0.3.arch1-9
uname -r: 7.0.3-arch1-9-ptl

Kernel/card:

0 [sofsoundwire]: sof-soundwire - sof-soundwire
                 LENOVO-83QK-YogaSlim7Ultra14IPH11-LNVNB161216

Loaded topology:

Topology file: intel/sof-ipc4-tplg/sof-arl-cs42l43-l2-cs35l56-l3-2ch.tplg
Lenovo 83QK: using topology NHLT blobs for PCH DMIC

PipeWire/UCM exposes the expected routes:

sof-soundwire Speaker
sof-soundwire Digital Microphone

Confirmed locally:

• built-in speakers work
• internal microphone records voice
• RT722 remains unattached but no longer blocks speaker routing
• no Dummy Output / missing-card failure on the final pkgrel=9 build

Test plan

• Build linux-ptl with makepkg
• Install linux-ptl and matching headers
• Boot patched kernel on Lenovo 83QK / 17aa:3821
• Confirm sof-soundwire card appears
• Confirm sof-arl-cs42l43-l2-cs35l56-l3-2ch.tplg is loaded
• Confirm CS35L57/CS35L56 speaker amp firmware/calibration loads
• Confirm built-in speakers are audible
• Confirm internal microphone records voice

Notes

This is validated on one Lenovo 83QK unit. The SoundWire/DMIC changes are subsystem-ID scoped to 17aa:3821 where possible.

[itisyb]

Follow-up for the internal microphone: the first Lenovo 83QK revision fixed speakers but forced dmic_num = 0, which disabled the actual PCH DMIC path. I updated 0033 to clamp the NHLT DMIC count from 4 to 2 instead, so the kernel should select the shipped sof-arl-cs42l43-l2-cs35l56-l3-2ch.tplg topology and keep PCH DMIC capture links. This is pushed as a0af275; it still needs a rebuild/reboot validation for mic capture.

[charleskeepax]

Yeah this looks like it needs updated, according to our notes this should have the MIC quirk it appears to have been missed when this was upstreamed. Are you able to send this upstream (I would move the comment to the commit message, no need for that in the code)? Or would you like me to send this one for you?

[charleskeepax]

Hang on, sorry no this should be pulling this from the ACPI these days. Lets start with the ACPI dump and then think this through.

[charleskeepax]

Would it be possible to get an acpidump for this laptop? Lets see if we can get Lenovo to fix this in the bios.

[itisyb]

Here's the ACPI dump from the Lenovo 83QK / Yoga Slim 7 Ultra 14IPH11:

• ZIP: https://raw.githubusercontent.com/itisyb/omarchy-pkgs/artifact-lenovo-83qk-acpi-dump/lenovo-83qk-acpi-sanitized.zip
• README/checksum: https://github.com/itisyb/omarchy-pkgs/tree/artifact-lenovo-83qk-acpi-dump

I sanitized the archive before sharing:

• DMI serial number and UUID are redacted.
• The MSDM ACPI table is omitted
• acpidump-redacted.dat is the original acpidump text with only the MSDM table block removed.

Firmware summary from DMI: LENOVO 83QK, Yoga Slim 7 Ultra 14IPH11, BIOS SHCN31WW / platform firmware rev 1.31, release date 03/18/2026.

Let me know if you need anything else happy to help :)

[charleskeepax]

Yeah ok the ACPI for our device looks good I think, but as you note there is a spurious rt722 in the ACPI. If you felt comfortable would you be able, back out your current fixes. Load an SSDT like:

DefinitionBlock ("", "SSDT", 2, "Test", "rt722", 0x00001000)
{
    External (_SB.PC00.HDAS.IDA.SNDW.SWD0, DeviceObj)
    Scope (\_SB.PC00.HDAS.IDA.SNDW.SWD0)
    {
        Method (_STA, 0, NotSerialized)
        {
            Return (Zero)
        }
    }
}

That should disable the rt722 such that the kernel will ignore it. Your kernel will also need this patch from upstream, if it doesn't already have it:

de67b4ea168f ("soundwire: slave: Don't register devices that are disabled in ACPI")

The let us know if the audio comes up fine after that, if it doesn't a dmesg of boot would be handy to get an idea of what when wrong. I will approach Lenovo about getting a BIOS update for this model but this test will hopefully let us check this is the only problem we have to solve.

[itisyb]

I tested the RT722 SSDT override path with my current Lenovo-specific fixes backed out, using a test linux-ptl 7.0.3.arch1-10 build that includes the upstream de67b4ea168f-equivalent SoundWire patch.

Result: audio still did not come up cleanly. The boot log still shows the RT722 device being used and repeated failures like:

rt722-sdca sdw:0:3:025d:0722:01: DPN_PortCtrl register write failed
soundwire sdw-master-0-3: Program transport params failed: -61

Sanitized artifacts are here:

• failure logs/state: https://raw.githubusercontent.com/itisyb/omarchy-pkgs/artifact-lenovo-83qk-rt722-ssdt-failed/lenovo-83qk-rt722-ssdt-failed-sanitized.zip
• sanitized ACPI dump again for convenience: https://raw.githubusercontent.com/itisyb/omarchy-pkgs/artifact-lenovo-83qk-rt722-ssdt-failed/lenovo-83qk-acpi-sanitized.zip
• README/checksums: https://github.com/itisyb/omarchy-pkgs/tree/artifact-lenovo-83qk-rt722-ssdt-failed

One caveat from the logs: I do not see evidence that the Test/rt722 SSDT override was actually loaded, and sdw:0:3:025d:0722:01 still appears under /sys/bus/soundwire/devices. I installed the AML into /etc/initcpio/acpi_override/rt722-disable.aml, but this Omarchy setup has an /etc/mkinitcpio.conf.d/omarchy_hooks.conf drop-in that appears to override the main HOOKS= line, so the acpi_override hook may not have made it into the booted UKI. The failure bundle includes system-state.log showing that state.

[charleskeepax]

Hmm... yeah I think for some reason the SSDT didn't apply there. Been mulling this over and I think perhaps this might be the best way to fix this:

https://github.com/thesofproject/linux/pull/5773/commits

Would you be able to try that fix and see where that gets to?