[BUG] alsabat test failed on LNL-NOCODEC platform

[keqiaozhang]

Describe the bug
This is a kernel regression form upstream merge, bisect result shows it caused by dc2efdb
From the console log, no signal detected:

2023-12-08 08:10:44 UTC [REMOTE_INFO] ktime=81 sof-test PID=1445: starting
2023-12-08 08:10:44 UTC [REMOTE_INFO] Run alsa setting for LNLM_RVP_NOCODEC
2023-12-08 08:10:44 UTC [REMOTE_INFO] Use reset_sof_volume function to set amixer setting.
2023-12-08 08:10:44 UTC [REMOTE_INFO] Starting /usr/local/bin/mtrace-reader.py >& /home/ubuntu/sof-test/logs/check-alsabat/2023-12-08-08:10:44-25107/mtrace.txt &
2023-12-08 08:10:44 UTC [REMOTE_INFO] check the PCMs before alsabat test
2023-12-08 08:10:47 UTC [REMOTE_COMMAND] alsabat -Phw:sofnocodec,0 --standalone -n 240000 -r 48000 -c 2 -f S16_LE -F 821 -k 2.1
2023-12-08 08:10:48 UTC [REMOTE_COMMAND] alsabat -Chw:sofnocodec,0 -c 2 -r 48000 -f S16_LE -F 821 -k 2.1
WARNING: Signal too weak!
 FAIL: Peak freq too low 13.92 Hz
 FAIL: Peak freq too low 27.83 Hz
 FAIL: Peak freq too low 35.89 Hz
 FAIL: Peak freq too low 106.93 Hz
 FAIL: Peak freq too low 118.65 Hz
 FAIL: Peak freq too low 123.05 Hz
 FAIL: Peak freq too low 149.41 Hz
 FAIL: Peak freq too low 170.65 Hz
 FAIL: Peak freq too low 197.02 Hz
 FAIL: Peak freq too low 244.63 Hz
alsa-utils version 1.2.6

Entering capture thread (ALSA).
Get period size: 2048  buffer size: 16384
Recording ...
Capture completed.

BAT analysis: signal has 65536 frames at 48000 Hz, 2 channels, 2 bytes per sample.

Channel 1 - Checking for target frequency 821.00 Hz
Amplitude: 9.3; Percentage: [0]
Detected peak at 13.92 Hz of 3.29 dB
 Total 3.3 dB from 13.92 to 13.92 Hz
Detected peak at 27.83 Hz of 3.44 dB
 Total 6.4 dB from 27.83 to 27.83 Hz
Detected peak at 35.89 Hz of 3.49 dB
 Total 8.2 dB from 35.89 to 35.89 Hz
Detected peak at 106.93 Hz of 3.15 dB
 Total 9.4 dB from 106.93 to 106.93 Hz
Detected peak at 118.65 Hz of 3.69 dB
 Total 10.4 dB from 118.65 to 118.65 Hz
Detected peak at 123.05 Hz of 3.51 dB
 Total 11.2 dB from 123.05 to 123.05 Hz
Detected peak at 149.41 Hz of 3.35 dB
 Total 11.9 dB from 149.41 to 149.41 Hz
Detected peak at 170.65 Hz of 3.81 dB
 Total 12.5 dB from 170.65 to 170.65 Hz
Detected peak at 197.02 Hz of 3.50 dB
 Total 13.0 dB from 197.02 to 197.02 Hz
Detected peak at 244.63 Hz of 3.47 dB
 Total 13.5 dB from 244.63 to 244.63 Hz
Detected at least 10 signal(s) in total

Return value is -1003

To Reproduce
~/sof-test/test-case/check-alsabat.sh -p hw:sofnocodec,0 -c hw:sofnocodec,0 -C 2 -F 821

Reproduction Rate
100%

Environment

1. Branch name and commit hash of the 2 repositories: sof (firmware/topology) and linux (kernel driver).
   • Kernel: {SHA}
   • SOF: {a41f26d085ce}
2. Name of the topology file
   • Topology: {sof-lnl-nocodec.tplg}
3. Name of the platform(s) on which the bug is observed.
   • Platform: {LNLM_RVP_NOCODEC}

dmesg.txt

[plbossart]

The problem showed on MTL NOCODEC and I wrote down it was a concern, see #4730 (comment)

But since there was no answer I went ahead and merged. Gah.

Sorry @ujfalusi and @bardliao you'll have to pick this one.

[ujfalusi]

#4730 got merged two days ago (~2023-12-06 ?)
The last passing alsabat was 35386 (2023-12-02)
The next one already failing: 35405 (2023-12-04) but not because of audio quality.

I guess we get the format_val wrong in generic_calc_stream()?

[plbossart]

yeah, this doesn't look quite right

[   84.434845] kernel: snd_sof:sof_ipc4_pcm_dai_link_fixup: sof-audio-pci-intel-lnl 0000:00:1f.3: Set NoCodec-0 to 32 bit format
[   84.434869] kernel: snd_sof_intel_hda_common:generic_calc_stream_format: sof-audio-pci-intel-lnl 0000:00:1f.3: configuring stream format for 0 channels, params_channels was 2
[   84.434871] kernel: snd_sof_intel_hda_common:generic_calc_stream_format: sof-audio-pci-intel-lnl 0000:00:1f.3: format_val=0x0, rate=48000, ch=0, format=10

the num_channels is determined by

	u32 ch_mask = 0;
	int i;

	/*
	 * if the multiple dais are handled by the same dailink, we may need to update the
	 * stream channel count - the params are modified in soc-pcm based on the ch_maps info
	 */
	for_each_link_ch_maps(rtd->dai_link, i, ch_maps)
		ch_mask |= ch_maps[i].ch_mask;

	num_channels = hweight_long(ch_mask);

So most likely this is a regression with the ch_maps stuff that's not done right for dummy dais.

[plbossart]

let's see if #4741 fixes the issue

[keqiaozhang]

@plbossart confirmed that #4741 can fix this issue.