[BUG][CML]DSP Panic occurred when pause/resume on aplay0,2(RT1308)

[YvonneYang2]

Describe the bug
DSP Panic occurred when pause/resume on aplay0,2(RT1308)
Revert commit 6713d90, issue is gone. It seems the change of commit 6713d90 has conflicts with thesofproject/linux#1897

To Reproduce

1. Boot up.
2. Run command via "aplay -Dhw:0,2 -r48000 -c2 -fs16_le wav/48California_Dreaming.wav -vv -i"
3. Do pause/resume, if issue not reproduced, please do more times.

Reproduced rate
100%
Only reboot can recover the issue.

Expected result
Pause/resume normally.

Actual result
Dmesg shows DSP Panic! only reboot can recover the issue.

Environment
kernel: topic/sof-dev commit a272777 + thesofproject/linux#1943 + thesofproject/linux#1897
FW: cml-011-drop-stable commit: 37ad771
tplg: cml-011-drop-stable + PR #2663 (set pipeline id 1 = 0x3 and pipeline id 2 = 0x4 in demux_coef_default)
platform: CML-U Laptop with ALC711+ ALC1308+ ALC715 in SDW mode

dmesg

[   41.660168] sof-audio-pci 0000:00:1f.3: pcm: trigger stream 2 dir 0 cmd 4
[   41.660803] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x2014001e successful
[   41.660807] sof-audio-pci 0000:00:1f.3: ipc tx: 0x60070000: GLB_STREAM_MSG: TRIG_RELEASE
[   41.662432] sof-audio-pci 0000:00:1f.3: error : DSP panic!
[   41.662435] sof-audio-pci 0000:00:1f.3: panic: dsp_oops_offset 788480 offset 788480
[   41.662437] sof-audio-pci 0000:00:1f.3: status: fw entered - code 00000005
[   41.662505] sof-audio-pci 0000:00:1f.3: error: can't enter idle
[   41.662505] sof-audio-pci 0000:00:1f.3: error: trace point 00004000
[   41.662506] sof-audio-pci 0000:00:1f.3: error: panic at src/lib/agent.c:60
[   41.662507] sof-audio-pci 0000:00:1f.3: error: DSP Firmware Oops
[   41.662508] sof-audio-pci 0000:00:1f.3: EXCCAUSE 0x0000003f EXCVADDR 0x00000000 PS       0x00060b25 SAR     0x00000000
[   41.662509] sof-audio-pci 0000:00:1f.3: EPC1     0x00000000 EPC2     0xbe02c1f6 EPC3     0x00000000 EPC4    0x00000000

Error_trace

         TIMESTAMP              DELTA C# COMPONENT          LOCATION                       CONTENT
[ 52070391.354167] ( 52070392.000000) c0 WAIT                         src/lib/wait.c:39    ERROR ewt
[ 52070427.812500] (       36.458332) c0 DMA                    src/drivers/dw/dma.c:362   ERROR dw_dma_release() error: dma 0 channel 1 timeout
[ 52068660.052083] (             nan) c0 IPC                       src/ipc/handler.c:441   ipc: comp 12 -> trigger cmd 0x70000
[ 52068673.750000] (       13.697917) c0 PIPE         3.17      src/audio/pipeline.c:673   pipe trigger cmd 3
[ 52068693.958333] (       20.208334) c0 DMA                    src/drivers/dw/dma.c:343   dw_dma_release(): dma 0 channel 1 release
[ 52070391.354167] (     1697.395874) c0 WAIT                         src/lib/wait.c:39    ERROR ewt
[ 52070410.989583] (       19.635416) c0 DMA                    src/drivers/dw/dma.c:413   dw_dma_stop(): dma 0 channel 1 stop
[ 52070427.812500] (       16.822916) c0 DMA                    src/drivers/dw/dma.c:362   ERROR dw_dma_release() error: dma 0 channel 1 timeout
[ 52070475.260417] (       47.447918) c0 SA                          src/lib/agent.c:56    perf sys_load peak plat 49927 cpu 180897

error_logger.log
logger.log
dmesg.log

[RanderWang]

https://github.com/thesofproject/sof/blob/master/src/drivers/dw/dma.c#L348. Since sdw controller is stopped first, then DSP is stopped, so DW FIFO will never be consumed, so timeout occurs, and watch dog will reset hardware.

[RanderWang]

@ktrzcinx can you check 1edaef6, it is only applied for BYT & CHT.

[ktrzcinx]

Thanks @RanderWang , @YvonneYang2 please check reproduction with changes from #2673

[YvonneYang2]

Issue can be reproduced with below test recipe:

kernel: topic/sof-dev branch commit 3bdd89d + thesofproject/linux#1943 + thesofproject/linux#1954 + thesofproject/linux#1897
FW: master branch commit 1e39cee

Then tried to apply #2673 on master, issue can be fixed.

[RanderWang]

thanks @ktrzcinx and @YvonneYang2 , so this PR is effective.

[slawblauciak]

As agreed with @plbossart pause/release operations are not supported on endpoints with multiple synchronized links.

However, I'd like to confirm if this issue will be reproducible on single-link endpoints with the pop fix on the kernel side. I believe the PR for that will be merged soon.

[YvonneYang2]

Since the issue could be reproduced with kernel topic/sof-dev + thesofproject/linux#1943 + thesofproject/linux#1954 + thesofproject/linux#1897, but now these PRs are replaced by thesofproject/linux#1982 and thesofproject/linux#1943, so retested them with latest thesofproject/linux#1897, issue can still be reproduced on cml-u.

Then checked it with topic/sof-dev (commit: eaae268)+ latest thesofproject/linux#1897 and master FW, issue can still be reproduced.

[slawblauciak]

Naturally, but I assume you tested it on aplay0,2, which is a case we don't support.
It should be tested on something that has a single link.

[plbossart]

As agreed with @plbossart pause/release operations are not supported on endpoints with multiple synchronized links.

We agreed to skip pause/release for synchronized links in a first version. It'll be needed for Chrome support.

[YvonneYang2]

Naturally, but I assume you tested it on aplay0,2, which is a case we don't support.
It should be tested on something that has a single link.

Commented as #2658 (comment), I tested with aplay0,2 on cml-u laptop which has a single link. Issue can still be reproduced.