[ghost]

when START command comes, the pipeline has to be prepared.
This case has to be taken into account:
when ALSA has XRUN, it will send stop/start commands to FW
and try to recover the pipepine. If we did not prepare
the pipeline before start, the recover process will fail.

Signed-off-by: Wu Zhigang zhigang.wu@linux.intel.com

[tlauda]

I've checked this change and it doesn't fix noise issue after stop - start sequence.

[lgirdwood]

It would be better to prepare it prior to restarting. You need to let the pipeline finish any pending work too.

[ghost]

@lgirdwood
Exactly, do the prepare after the pipeline stop immediately, the dai and gp-dma is still on stopping.
I will refine it.

@tlauda
Yes, could you check this patch in this step:

1. do the aplay and do the arecord at the same time.
2. frequently pause/release the aplay to check the arecord stopped or not, and check dsp panic or not?
3. frequently pause/release the arecord to check the aplay stopped or not, and check dsp panic or not?

[tlauda]

@zhigang-wu
I haven't checked those scenarios, but it doesn't change the fact that with your patch there is still noise issue.

[ghost]

I update the code and move the pipeline_prepare before the pipeline_trigger() function.
this prepare only enable at the start command comes.
I found the prepare logic is also used in the common_test.c file.

My test is to enable the aplay and arecord both.

@lgirdwood
This PR is conflicted with PR #124.
you can choose which PR is better.

@tlauda
I do the test to check the noise, there is no such noise.
but on my GP platform, it can produce the ALSA XRUN by itself.
after the recover from xrun status, it does not have the noise.
the XRUN is not frequently, maybe it is the reason.

[tlauda]

@zhigang-wu
Actually it's not conflicted, because your prepare function will set pointer_init=0.
Still I have doubts about this solution and whether it works.
@xiulipan @keqiaozhang Can you confirm if this fixes the noise issue?

[ghost]

@tlauda
on my GP platform, i built with gcc.
the noise will happen when i enable the aplay (i means keep both of the PRs).
pause and release again, the noise will gone.
the second pause and release, the noise will come back.
one time is ok, the next time is wrong.

[tlauda]

If adding prepare doesn't change anything, why to bother?

[ghost]

@lgirdwood
I have question about this PR:
do you think the prepare() function can reset the pipeline into the status when the playback is ready to play at the first time?
If it can not, which part we still missed in this prepare() operation?

[tlauda]

@zhigang-wu
The problem here is the status of Host DMA.
When calling prepare you are resetting the pointers of the buffers and also resetting the linked list of the GPDMA channel. What you cannot do from the DSP side is reset the Host DMA. After toggling GEN bit you are assuming that the buffers should be filled from the beginning, but it's not necessary true. To achieve such reset the host stream should be set into reset state from the kernel side.

[ghost]

@tlauda
If it is true as you said, could we reset the host stream from kernel side.
If it is possible, that would make the bug fix more simple than now.
and which register is for this host stream reset? could you tell me?