[BUG][ADL][TGL] playback failed at the second run with ipc tx error for 0x60010000 GLB_STREAM_MSG: PCM_PARAMS

[keqiaozhang]

Describe the bug
In today's CI tests, we found that playback failed with IPC tx error at the second run on almost all our platforms.

[   41.385988] snd_sof:ipc3_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x60010000: GLB_STREAM_MSG: PCM_PARAMS
[   41.386111] sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx error for 0x60010000 (msg/reply size: 108/20): -22
[   41.386221] sof-audio-pci-intel-tgl 0000:00:1f.3: HW params ipc failed for stream 1
[   41.386222] sof-audio-pci-intel-tgl 0000:00:1f.3: ASoC: error at snd_soc_pcm_component_hw_params on 0000:00:1f.3: -22
[   41.386240]  Jack Out: ASoC: error at __soc_pcm_hw_params on Jack Out: -22
[   41.386244] sdw_deprepare_stream: subdevice #0-Playback: inconsistent state state 1
[   41.386247] snd_sof:ipc3_log_header: sof-audio-pci-intel-tgl 0000:00:1f.3: ipc tx: 0x80010000: GLB_DAI_MSG: CONFIG
[   41.386569]  Jack Out: ASoC: error at dpcm_fe_dai_hw_params on Jack Out: -22

This is a kernel regression and caused by 6e2cdc2.

ASoC: SOF: Introduce struct snd_sof_pipeline
Introduce struct snd_sof_pipeline to save the information about
pipelines including the pipeline widget, their status wrt how many PCM's
are using them and whether they are complete or not.

In struct snd_sof_widget, replace pipe_widget with spipe and remove
complete. In struct snd_sof_pcm_stream_pipeline_list, replace
pipe_widgets with pipelines.

Update all users accordingly.

Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
 [topic/sof-dev](https://github.com/thesofproject/linux) ([#3957](https://github.com/thesofproject/linux/pull/3957))

To Reproduce
run aplay -Dhw:0,0 -r 48000 -c 2 -f S16_LE -d 3 /dev/zero -v -q twice.

Reproduction Rate
100%

dmesg.txt

[plbossart]

@keqiaozhang @ranj063 is there a reason why CI didn't catch this issue earlier during PR tests? Is this a disconnect between PR tests and daily tests? It's ok to make mistakes, but our CI should catch issues.

[ranj063]

@keqiaozhang @ranj063 is there a reason why CI didn't catch this issue earlier during PR tests? Is this a disconnect between PR tests and daily tests? It's ok to make mistakes, but our CI should catch issues.

@plbossart CI did catch this but we missed it. I think with the 01.org migration going, we should have looked at both test results for a PR in the dashboard but the name "pr" for the device test fooled us. It's only for IPC4 and IPC3 is covered by the "stable_v2_2_PR" test