DMIC Capture failure on HDA with cavs2.5

[ranj063]

All capture usecases are failing with the following error

[  273.932645] kernel: snd_sof:snd_sof_get_nhlt_endpoint_data: sof-audio-pci-intel-tgl 0000:00:1f.3: dai index 0 nhlt type 2 direction 1 dev type 0
[  273.932650] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: no matching blob for sample rate: 48000 sample width: 16 channels: 4
[  273.932704] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: failed to prepare widget dai-copier.DMIC.dmic01.capture
[  273.932740] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: Failed to prepare connected widgets
[  273.932770] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: error: failed widget list set up for pcm 6 dir 1
[  273.932803] kernel: sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_pcm_component_hw_params on 0000:00:1f.3: -22

Zephyr Daily test plan "daily_test_new"[*]: 46733, 46770

[*] string can be used as a filter in the URL

[ranj063]

I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

[marc-hb]

Looking at result/planresult?planname=%5Edaily_test_new,

• Last successful daily run was 46534

Start Time: 2024-10-04 13:21:25 UT
Linux Commit: 62f484728981
KConfig Commit: 8189104a4f38
SOF Commit: 9cdef9fc13bb
Zephyr Commit: 155f3f3ba688

• First failing daily run 46595

Start Time: 2024-10-10 13:11:05 UTC
Linux Commit: 7eab5d86f218
KConfig Commit: 8189104a4f38
SOF Commit: d2cf7c3cc859
Zephyr Commit: 155f3f3ba688

There's a very clear and dramatic drop in the PASS rate between these two consecutive runs. There's a big date gap between the two because of a planned power outage in Oregon during that week-end.

(It's less clear but I suspect the PASS rate of result/planresult?planname=%5Edaily_lnl dropped at around the same time...? Harder to tell because unlike the other it's always been somewhat red so, as expected everyone stopped paying attention.)

[lgirdwood]

I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

@ranj063 So does this mean kernel cant find blob or the 32bit blob is missing form the topology(i.e. topology has 16bit blob only) ?

[ranj063]

I checked the device and it looks like we're using the tplg NHLT and it fails to find the 32-bit DMIC blob. If I remove the module param to force the tplg NHLT, the test passes.

@ranj063 So does this mean kernel cant find blob or the 32bit blob is missing form the topology(i.e. topology has 16bit blob only) ?

@lgirdwood it looks like the 32-bit blob is missing from the topology. Im verifying it this morning

[ranj063]

the reason for the fialure was that the incorrect topology was being used on the device. For cavs2.5 platforms, when forcing the use of topology NHLT, we should copy sof-hda-generic-cavs25-4ch.tplg into sof-hda-generic-4ch.tplg before running the CI tests. But if the NHLT is included in the BIOS, that should be preferred over the topology NHLT.

[marc-hb]

46891 passed, no idea why.

(It's less clear but I suspect the PASS rate of result/planresult?planname=%5Edaily_lnl dropped at around the same time...? Harder to tell because unlike the other it's always been somewhat red so, as expected everyone stopped paying attention.)

This recent, probably unrelated LNL regression and crash seems to be focused on multiple-pipeline tests. Has anyone filed a bug yet?

Here's a non-daily, public example: https://sof-ci.01.org/softestpr/PR1236/build782/devicetest/index.html

[marc-hb]

This recent, probably unrelated LNL regression and crash seems to be focused on multiple-pipeline tests. Has anyone filed a bug yet?

• [BUG] multiple-pipeline-capture-50 fails on LNL #9593

Thanks @kv2019i