[BUG][playback] Underrun after pause-release on HDA Link pipelines

There is a random underrun after pause-release sequence done on HDA Link pipelines. Repro rate is under 5%. It shows up during CI tests. It looks like Link DMA doesn't copy anything after release, so DSP has no free space for copying data from buffer.
There are two possibilities that we could check:

See if the right Link DMA is started by kernel after release. I remember that we've already had such problem before.
Fix sequence of pausing/stopping the pipelines. Kernel should first send pause/stop ipc to the FW and only then deassert stream RUN bit. Doing it other way around can potentially lead to incrementing Gateway FPI by the DSP, when RUN bit is already 0 and such behavior can have undefined consequences.

@mengdonglin

@mengdonglin @wenqingfu Could you assign someone to this issue? It's randomly failing CI.

Xiuli is fixing PCM STOP sequence in #1169

But we still need to fix PCM PAUSE sequence for the rendering pipeline here , please see comment:　#1169 (comment)

Pause/release problem on capture is a different issue and tracked by thesofproject/sof#1760

@mengdonglin

But we still need to fix PCM PAUSE sequence for the rendering pipeline here , please see comment:　#1169 (comment)

@mengdonglin PR #1169 addresses both the STOP and the PAUSE sequence. And I am having a very hard time reproducing this issue with that PR. Could we have a stress test run with this PR to make sure this is still reproducible?

@tlauda

@tlauda there's no changes in my kernel. What I meant was that I am able to hit this issue on APL with or without the kernel PR #1169 which switches the order in which the IPC is sent and the DMA is stopped/started.

I just tried the FW PR 1891 and still hit the issue as well.

@tlauda

@tlauda I am in the process of implementing the nocodec support for link DMA and I had a couple of questions for you:

Just like we have the nocodec support for SSP, does it make sense to do the same for Link DMA?
If so, the idea is to not initialize the i915 and probe the codecs. Is it just enough if I have pick a Link DMA stream tag and start the stream for such a mode to work?

@ranj063

@ranj063 Change in stop sequence was also needed, but it doesn't fix this particular problem. We also have a problem with start sequence. You cannot start pipeline in FW and start Link DMA after that. It needs to be the other way around. Could you try to make such change in kernel and see if you still see the issue?
As for nocodec mode, I don't think it's going to work. There needs to be something, that will consume the data from the link. Without the codec I think that DSP will see full buffer gateway all the time and it'll end up in overrun.

@ranj063

@ranj063 Change in stop sequence was also needed, but it doesn't fix this particular problem. We also have a problem with start sequence. You cannot start pipeline in FW and start Link DMA after that. It needs to be the other way around. Could you try to make such change in kernel and see if you still see the issue?
As for nocodec mode, I don't think it's going to work. There needs to be something, that will consume the data from the link. Without the codec I think that DSP will see full buffer gateway all the time and it'll end up in overrun.

@ranj063 Change in stop sequence was also needed, but it doesn't fix this particular problem. We also have a problem with start sequence. You cannot start pipeline in FW and start Link DMA after that. It needs to be the other way around. Could you try to make such change in kernel and see if you still see the issue?

@tlauda the START/RELEASE sequence in the kernel already does start Link DMA and then send the START IPC.

@tlauda

As for nocodec mode, I don't think it's going to work. There needs to be something, that will consume the data from the link. Without the codec I think that DSP will see full buffer gateway all the time and it'll end up in overrun.

@tlauda are you sure about this? @plbossart suggested that this should work even if there is no codec to consume the data.

ASoC: pcm: update FE/BE trigger order based on the command

On 10/3/19 9:29 AM, Ranjani Sridharan wrote: As for nocodec mode, I don't think it's going to work. There needs to be something, that will consume the data from the link. Without the codec I think that DSP will see full buffer gateway all the time and it'll end up in overrun. @tlauda <https://github.com/tlauda> are you sure about this? @plbossart <https://github.com/plbossart> suggested that this should work even if there is no codec to consume the data.

Yes, the PCH owns the clock and can push data out even if there is no codec consuming the data. The example I have in mind is sending audio to the HDMI devices in legacu mode when there is no HDMI link. It just consumes data at the usual 48kHz rate.

ASoC: pcm: update FE/BE trigger order based on the command

Navigation Menu

Repository navigation

[BUG][playback] Underrun after pause-release on HDA Link pipelines #1160

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[BUG][playback] Underrun after pause-release on HDA Link pipelines #1160

Description

Activity

tlauda commented on Aug 27, 2019

mengdonglin commented on Sep 9, 2019

mengdonglin commented on Sep 9, 2019

ranj063 commented on Sep 16, 2019

12 remaining items

ranj063 commented on Oct 2, 2019

ranj063 commented on Oct 3, 2019

tlauda commented on Oct 3, 2019

ranj063 commented on Oct 3, 2019

ranj063 commented on Oct 3, 2019

plbossart commented on Oct 4, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions