[BUG] ALSA: hda/tas2781: tuning is not restored after PCM close/reopen

[lhxll07]

Summary

On a Lenovo Yoga Pro 16s IMH9 engineering sample with four TAS2781 amplifiers,
the first playback after forcing a firmware load sounds correct, but closing
and reopening the speaker PCM can leave the amplifiers with thin and distorted
output. The selected program/configuration remains cached, so the OPEN path
can skip reloading the tuning that the CLOSE path has partially shut down.

This is separate from runtime PM: it is reproducible while both the HDA/SOF
controller and the TAS2781 device have power/control=on.

Hardware and software

System: Lenovo Yoga Pro 16s IMH9 engineering sample
DMI product_name: 0000
DMI product_family/version: YOGA Pro 16s IMH9
Audio controller: Intel Meteor Lake-P HD Audio 8086:7e28, subsystem 17aa:3811
Codec: Realtek ALC287, subsystem 17aa:38d6
Amplifiers: ACPI TIAS2781, subsystem 17aa:38d6, four devices
Kernel: 7.1.4-arch1-1

The machine uses TAS2XXX38D6.bin from its Lenovo Windows recovery image. Its
SHA-256 is:

014c2689267436b7b2f03fe472c38beee02c730c9a2c818c657e8ac05adc7366

I am not attaching or redistributing that vendor binary in this report.

For comparison, the current linux-firmware file with the same name has
SHA-256 79f116576ba8b9ffdf7d595f331d010a947157a3d62558602149c45b67371803.
Both files are 63628 bytes and use PPC version 0x16000 / driver version
0x100, but differ by 314 bytes. The upstream file is dated 2023-12-19 and
contains configuration string 38D6_Veco...s3_0; the working recovery file is
dated 2023-12-29 and contains xxx...s1_0. Could TI/Lenovo please clarify
whether these represent different speaker/ES variants and which file belongs
to subsystem 17aa:38d6?

Reproduction

1. Set Speaker Force Firmware Load to on and open the speaker PCM. Output
   is full-range and sounds correct.
2. Close the PCM so the HDA playback hook runs HDA_GEN_PCM_ACT_CLOSE.
3. Reopen the same PCM. Output is now thin/distorted rather than merely quieter.
4. Force another firmware load and reopen the PCM. Correct output returns.

This occurred repeatedly while diagnosing the machine.

Isolation results

• Keeping both the HDA/SOF PCI function and TAS2781 I2C runtime-PM controls at
  on did not prevent the degradation after PCM CLOSE/reopen.
• Preventing WirePlumber from closing only the internal Speaker PCM kept the
  sound correct indefinitely.
• Allowing the PCM to close, then setting Speaker Force Firmware Load=on
  before the next power-up restored correct sound.

These results point to the PCM CLOSE/OPEN state transition, not only to a
runtime suspend/resume problem.

Suspected driver state mismatch

Current topic/sof-dev at 15c9b701ada608fc3310f4bc2b3e48cbfec206d3
does the following in
sound/hda/codecs/side-codecs/tas2781_hda_i2c.c:

case HDA_GEN_PCM_ACT_OPEN:
        pm_runtime_get_sync(dev);
        tasdevice_tuning_switch(tas_hda->priv, 0);
        break;
case HDA_GEN_PCM_ACT_CLOSE:
        tasdevice_tuning_switch(tas_hda->priv, 1);
        pm_runtime_put_autosuspend(dev);
        break;

tasdevice_tuning_switch(..., 1) executes the PRE_SHUTDOWN block. On the
next OPEN, tasdevice_tuning_switch(..., 0) calls
tasdevice_select_tuningprm_cfg() with the cached cur_prog/cur_conf.
Because these still equal the requested values, the program/configuration load
can be skipped (Unneeded loading dsp conf 0), followed only by
PRE_POWER_UP.

System resume explicitly invalidates each device's cur_prog and cur_conf
before restoring state; PCM CLOSE does not.

Expected behavior

Closing and reopening an unchanged speaker PCM should restore the exact tuning
state required for normal output without requiring a userspace force-load
control or keeping the PCM permanently open.

Related report

This may also explain the TAS2781 resume delay observed in #5543, where the
TAS2781 playback hook accounted for about 1.55 seconds before SOF PCM OPEN.

Please let me know which dynamic-debug traces or register dumps would be most
useful. I can test a proposed patch on the affected hardware.