[PATCH v2 0/3] ASoC: fix SoundWire audio on HP OmniBook X Flip 14 (ACP7.1 + TAS2783)

On the HP OmniBook X Flip 14-kc0xxx (board 8EA1, ACP PCI 1022:15e2 rev
0x71) no analog audio works: no speakers, no headset jack, no headset
microphone. Only HDMI and the PDM microphone come up.

The machine has two TI TAS2783 SmartAmps on SoundWire link 0 (unique_id
0x9 and 0xC) and a Realtek RT712-VB on link 1. A matching entry already
exists in snd_soc_acpi_amd_acp70_sdw_machines[], and the TAS2783
codec_info entry already carries .component_name, so those parts are
done. Three problems remain.

Patch 1 is board specific: the BIOS never exposes
"acp-audio-config-flag", so the ACP config lookup falls back to
FLAG_AMD_LEGACY_ONLY_DMIC, snd_pci_ps declines to probe and snd_acp_pci
binds instead. SoundWire never comes up at all, so the existing machine
entry is never reached.

Patches 2 and 3 are not board specific:

 - 2 makes the driver find factory calibration data that some OEMs store
   under a different vendor GUID. Affected machines run the amplifiers
   on generic defaults with nothing to indicate anything is wrong; the
   symptom is distortion at higher volumes.

 - 3 fixes silent amplifiers after system sleep for aggregated TAS2783
   pairs.

All three have been running on the affected machine: speakers, headset
jack and microphones work, and audio survives suspend/resume.

To be clear about what was tested where: the changes were developed and
runtime tested against v7.0 (Ubuntu 7.0.0-30), then rebased onto
for-next. The rebased form is checkpatch clean and builds warning-free
(sound/soc/codecs/tas2783-sdw.o and sound/soc/amd/acp-config.o), but the
runtime testing was done with the v7.0 form of the same changes - I have
not booted a for-next kernel on this machine.

Two things I did not turn into patches, because I would rather ask.

First, firmware lookup. tas_generate_fw_name() builds a flat name, so on
this board it asks for "8EA1-0-0x9.bin" and then "8EA1-0-9.bin".
linux-firmware ships these blobs as ti/audio/tas2783/8EXX-X-9.bin and
ti/audio/tas2783/8EXX-X-C.bin, i.e. under a subdirectory and with what
look like wildcard components for the board id and the link. The driver
prepends no path and implements no 8EXX fallback, so the firmware is
never found and playback fails with -EINVAL. Locally I worked around it
with symlinks under /lib/firmware/updates. Should the driver prepend
ti/audio/tas2783/ and fall back to the 8EXX-X- form, or is
linux-firmware expected to ship per-board names?

Second, channel order. tas2783x2_l0u9c_adr[] maps unique_id 0xC to
spk_l_endpoint and 0x9 to spk_r_endpoint. On this unit that appears to
be the wrong way round: with 0x9 as left and 0xC as right, a
left-channel-only tone comes out of the left speaker. I have only one
machine, so I have not sent a patch for it - can anyone with the same
board confirm?

jml (3):
  ASoC: amd: acp-config: override ACP config flag on HP OmniBook X Flip
    14
  ASoC: tas2783: also look for calibration data under the OEM GUID
  ASoC: tas2783: re-initialise amplifiers from .startup after system
    sleep

 sound/soc/amd/acp-config.c     |   7 ++
 sound/soc/codecs/tas2783-sdw.c | 130 ++++++++++++++++++++++++++++-----
 2 files changed, 120 insertions(+), 17 deletions(-)

-- 
2.53.0

jml (3):
  ASoC: amd: acp-config: override ACP config flag on HP OmniBook X Flip
    14
  ASoC: tas2783: also look for calibration data under the OEM GUID
  ASoC: tas2783: re-initialise amplifiers from .startup after system
    sleep

 sound/soc/amd/acp-config.c     |   7 ++
 sound/soc/codecs/tas2783-sdw.c | 130 ++++++++++++++++++++++++++++-----
 2 files changed, 120 insertions(+), 17 deletions(-)

-- 
2.53.0