Playback thread be killed immediately after run aplay.

[ZhendanYang]

Summary:
playback will be killed immediately after I run "aplay -D hw:0,0 -c 2 -r 48000 -f s16_le music.wav --period-size=192 --buffer-size=384 -vv -i", and we can find ipc time out in dmesg

Reproduce steps:

1. aplay -D hw:0,0 -c 2 -r 48000 -f s16_le music.wav --period-size=192 --buffer-size=384 -vv -i
2. terminal will show "killed" and then dmesg
   (It can not easily reproduce on up^2, but more easy to reprodude on GP)

Environment:
on two apl platforms, below is environment on up^2
sof ：
stable 1.2 : 7346243 on up^2
glk-003-branch 678cf3f on GP
soft ： 41861aa
sof-dev : f9c923e5ca9b38df7ddc71f26b55eb2bd1ffed46
tplg: sof-apl-nocodec.tplg, sof-apl-tdf8532.tplg

Log：
dmesg-killed.log
rmbox-t-killed.log

[lgirdwood]

This looks like two issues.

@zhigang-wu driver error handling code in sof_pcm_close is deref a NULL pointer probably as part of cleanup.
@RanderWang the FW part could be related to the scheduler. Can we try this with your new fix.

@lgirdwood
OK, I will move on this to root cause it.

from the demsg log, it shows several points:

1. it does more than one firmware load.
2. before the last firmware load, there is log "[ 9.952385] sof-audio sof-audio: tag 1 not opened!"
   it seems the free playback or capture stream at the abnormal status.
3. I checked the dmesg log. it has some suspend/resume operation.

it seems the kernel dos suspend/resume operation, there is incorrect status
between the two operations. so the last firmware restore hit the IPC timeout.
which trigger the failure process in our system. we hit the null pointer issue.
kernel panic happens.

I will add more trace to confirm the analysis tomorrow.
any idea is welcomes.

the kernel panic's root cause is found:

1. when the DSP firmware has problems: ipc timeout, it will stop the sof' resume process.
   then the pointer of substream->runtime->private_data will not be allocated.
2. because of the resume process stopped, the suspend operation will start.
   the suspend process will enter the hda_dsp_pcm_close() function to access this NULL pointer.
   the kernel panic issue will happened.
3. in normal process, our kernel's driver (pm feature) will not have this issue. because of DSP's
   problem, it triggers the abnormal process. but we did not handle it correctly.

I will check more code to figure out a better solution for this kernel's issue.

[lgirdwood]

@zhigang-wu lets check this is suspend process, if its NULL then we just return an error and dont suspend.