Comment 260 for bug 1958019

(In reply to TT from comment #236)
> I experienced the same as Comment #230 and Comment #231 in Ubuntu 20.04.2
> kernel 5.8.0-55.
>
> BTW, have you seen this windows program to get the dumps? RtHDDump_V236.zip
> It is suggested suggested by Hui Wang that has contributions to the Realtek
> patches. Sources:
> - https://asus-linux.org/blog/sound-2021-01-11/#getting-dumps
> - https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922
> - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1851518
> I have windows installed in another partition and may try it later.
> We may have already the coeffs to make it work but this may show something
> extra.

I've tried to follow some ideas in the dump. Don't know if that brings anybody further insights.

# 1. enables output of COEF
echo 1 |sudo tee /sys/module/snd_hda_codec/parameters/dump_coef
# shows the result for the ALC287
cat /proc/asound/card0/codec#0
# thus allowing to dump the different COEF register states after several actions

=> if I'm comparing the output before and after S3 resume, I can't see a significant difference

# 2. enable hda traces
echo 1 | sudo tee /sys/kernel/debug/tracing/events/hda/enable
# read traces
sudo cat /sys/kernel/debug/tracing/trace >/tmp/1
# result in output like:
# alsa-sink-HDA A-1107 [000] .... 9249.632894: hda_send_cmd: [0000:00:1f.3:0] val=0x00170500
hda-decode-verb 0x00170500
raw value = 0x00170500
cid = 0, nid = 0x01, verb = 0x705, parm = 0x00
raw value: verb = 0x705, parm = 0x0
verbname = set_power_state

My main idea is that there must something happen after a S3 resume which leads to a working speaker config, and it must be in the driver code?

I've tried to catch that and will upload the results soon ...

Additionally looking in the kernel code you see:
- HDA_CODEC_ENTRY(0x10ec0287, "ALC287", patch_alc269)
- for alc269 you find
- codec->patch_ops.resume = alc269_resume; => special resume handling
- in alc269_resume:
/* on some machine, the BIOS will clear the codec gpio data when enter
 * suspend, and won't restore the data after resume, so we restore it
 * in the driver.
*/

=> would explain, why S3 resume is working
- maybe some additonal toggle_power_output commands are also helpful

Is that something which can be helpful or a complete misleading path?