[But][TGL Chrome I2S] Headset audio output is harsh after runtime PM suspended.

[ClarexZhou]

Describe the bug
We found this issue on TGL chromebook with 98373 in I2S mode.
Headset audio output is harsh and each channel can output both L and R after runtime PM suspend.

To Reproduce

1. boot up system, runtime PM keeps active.

$cat /sys/bus/pci/devices/0000\:00\:1f.3/power/runtime_status

"Left Spk Switch" and "Right Spk Switch" is on, amixer is here
amixerContents.txt
2. Trigger headset playback via "speaker-test -Dhw:0,1 -t wav -c 2" and stop to check, headset audio output works ok. But runtime PM keeps active,
3. Trigger 373-spk playabck and DSM capture via "aplay -Dhw:0,0 -f s32_le -c 2 -r 48000 sine_48k_32bit_10s_stereo_l5_r2.wav -d 5 & arecord -Dhw:0,0 -f s32_le -c 4 -r 48000 record.wav -d 5 -vv -i" and stop to check, runtime PM auto enter suspended successfully.
4. Trigger headset playback again via "speaker-test -Dhw:0,1 -t wav -c 2", to check audio ouput

Actual result:
Headset audio output quality is very bad (1 channel output both 2 channels output, and the sound is harsh), but runtime PM can auto enter suspended after stop stream. Amixer contents is here
amixerContents_afterRuntimePmSuspend.txt
dmesg and sof logger as below:
dmesg.txt
full_soflogger_afterPMsuspended.txt

No difference for 5682 register, check via /sys/kernel/debug/regmap/i2c-10EC5682:00/registers
afterboot log was caught after above step1, which runtime PM always active, and headset output is good.
after373playback log was caught after above step3, which runtime PM works ok and headset output got issue
Loopback headset output audio are in
headset_output.zip

5682_register_afterboot.txt
5682_register_afterboot_afterheadsetplayback.txt
5682_register_after373playback.txt
5682_register_after373playback_afterheadsetplayback.txt
5682_register_after373_duringheadsetplayback.txt
5682_register_afterboot_duringheadsetplayback.txt

Reproduction Rate
10/10

Expected behavior
Headset audio output normally.

Environment
Kernel:https://github.com/thesofproject/linux/commits/topic/sof-dev commit:01ec165d
Revert regression on USB-C 6a7c533
Revert regression on PINCTRL cd0a323 + hack commit 6769df9
FW:: https://github.com/thesofproject/sof/tree/tgl-006-drop-stable plus thesofproject/sof#3006
TPLG: sof-tgl-max98373-rt5682.tplg
Platform: TGL chromebook with rt5682-max98373 in I2S mode

[plbossart]

@ClarexZhou it's really hard to analyze amixer contents, there's just too much information.

Can you provide the amixer commands and settings used, and make sure they are aligned with recommended values for rt5682, e.g. https://github.com/thesofproject/alsa-ucm-conf/blob/master/ucm2/sof-soundwire/RT5682.conf

Also can you confirm that you don't see any changes to register settings for rt5682 before and after suspend? The best way to do this would actually to dump the rt5682 registers from /sys/kernel/debug/regmap/i2c /registers , i.e. not just look at control values.

Thanks!

[ClarexZhou]

@plbossart , for amixer contents when issue seen or not : Only "Left Spk Switch" and "Right Spk Switch" are different, see comments
#2053 (comment).
Also no difference of /sys/kernel/debug/regmap/i2c-10EC5682:00/registers

[keyonjie]

This issue is root caused and fixed, I will submit PR soon.

[keyonjie]

@ClarexZhou thesofproject/sof#3053 is created to fix this.
@RDharageswari @sathya-nujella FYI. In case you hit issues in 5682 playback.

[keyonjie]

@plbossart it is root caused to be the mclk issue, the mclk provided to the rt5682 is 38.4MHz though it is claimed to be 19.2MHz in the error case.

[ClarexZhou]

Verified, error can be fixed by thesofproject/sof#3053