No audio route to MAX98390 amp on Samsung 940XHA (Lunar Lake) — generic HDA topology only

[Carlgo11]

No audio from internal speakers on Samsung Galaxy Book 940XHA — MAX98390 amp never wired into SOF topology

Summary

Internal speakers on a Samsung 940XHA (Lunar Lake / Core Ultra 200V) produce no audio. The machine uses the generic skl_hda_dsp_generic machine driver + sof-hda-generic-2ch.tplg topology, which only exposes the plain ALC298 HDA analog output. The board actually has a Maxim MAX98390 smart amplifier sitting between the codec and the physical speakers, and nothing in the current SOF stack routes audio to it.

Separately, snd-soc-max98390's ACPI match table only lists MX98390, while this board's firmware enumerates the chip as MAX98390 — so even manual driver binding requires a one-character fix, and normal automatic probing skips it entirely.

System

• Model: Samsung Electronics 940XHA (P04VAJ), NP944XHA_KG2SE
• BIOS date: 2025-01-14
• CPU platform: Intel Core Ultra 200V (Lunar Lake)
• Kernel: 7.1.8-arch1-3 (Arch Linux)
• sof-firmware: 2025.12.2-1 (intel/sof-ipc4/lnl/sof-lnl.ri, firmware version 2.14.1.1)
• Topology loaded: intel/sof-ipc4-tplg/sof-hda-generic-2ch.tplg
• Machine driver: skl_hda_dsp_generic (generic fallback — no board-specific driver matched)
• Codec: Realtek ALC298 (via snd_hda_codec_alc269)

Evidence the amp exists but is unused

/sys/bus/acpi/devices/ enumerates the amp as an I2C device:

$ ls /sys/bus/i2c/devices/ | grep -i max98390
i2c-MAX98390:00

But no driver is bound, and dmesg has zero mentions of it at boot — it's never even probed:

$ lsmod | grep max98390
(nothing)
$ ls /sys/bus/i2c/devices/i2c-MAX98390:00/driver
ls: cannot access '.../driver': No such file or directory

modinfo snd-soc-max98390 shows why:

alias:          i2c:max98390
alias:          acpi*:MX98390:*

The driver's ACPI ID table (sound/soc/codecs/max98390.c) only lists "MX98390":

static const struct acpi_device_id max98390_acpi_match[] = {
	{ "MX98390", 0 },
	{},
};

but this board's ACPI HID is MAX98390 (full spelling) — confirmed via:

$ readlink -f /sys/bus/i2c/devices/i2c-MAX98390:00
/sys/devices/pci0000:00/0000:00:15.2/i2c_designware.2/i2c-2/i2c-MAX98390:00

Testing done

1. Confirmed the full software stack is otherwise healthy: PulseAudio/PipeWire routing, ALSA mixer (Master/Speaker/Pre+Post Mixer all unmuted, 100%), codec pin register state (node 0x17: EAPD enabled, Pin-ctl OUT, unmuted) all check out.
2. Bluetooth audio output works normally, confirming the general audio pipeline (apps → PulseAudio) is fine — the fault is isolated to the internal-speaker path only.
3. speaker-test -D hw:0,0 opens cleanly, streams a full period at the correct rate with zero xruns/errors in dmesg — the DSP pipeline to the HDA analog pin is functioning correctly, it's just not connected to the amp.
4. As a local experiment, added "MAX98390" alongside "MX98390" in max98390_acpi_match[], rebuilt snd-soc-max98390.ko out-of-tree against the running kernel headers, and loaded it in place of the stock module. The driver does then bind and successfully talks to the chip:

[  332.793438] max98390 i2c-MAX98390:00: no optional property 'temperature_calib' found, default:
[  332.793447] max98390 i2c-MAX98390:00: no optional property 'r0_calib' found, default:
[  332.793449] max98390 i2c-MAX98390:00: max98390_i2c_probe: r0_calib: 0x0,temperature_calib: 0x0
[  332.793798] max98390 i2c-MAX98390:00: MAX98390 revisionID: 0x42

Confirms the amp is physically fine and reachable — this is not dead hardware.

5. However, even with the codec driver bound, no DAPM widget in the loaded topology references it:

$ grep -rl max98390 /sys/kernel/debug/asoc/*/dapm/* 
(no matches)

Audio still plays out through the plain HDA analog pin only, silently, because nothing in sof-hda-generic-2ch.tplg or the skl_hda_dsp_generic machine driver defines a pipeline/DAI link to this amp.

What's actually needed

This board needs proper SOF board support: a machine driver (or quirk entry) that recognizes the MAX98390 component and selects a topology with a pipeline/DAI link routing to it over I2S/SSP, the way other MAX98390-based laptops are already supported. The ACPI ID fix above is a trivial prerequisite, not the actual fix.

Ask

• Is there existing (or in-progress) SOF board support for Samsung 940XHA / similar Lunar Lake + MAX98390 designs that we're just not picking up?
• If not, what's the right entry point to get board support added — is a machine-driver/topology contribution from someone with the hardware in hand (happy to test patches) the right path?

Attachments

alsa-info.sh output and full acpidump for this machine: https://gist.github.com/Carlgo11/9a0ed91d7b08ac2ae693f53f7089db19

Happy to test any candidate patches — this is a daily-driver machine so I can iterate quickly.