Skip to content

bug fix: "DSP panic" when ALSA XRUN recovery #88

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ghost wants to merge 3 commits into from
Closed

bug fix: "DSP panic" when ALSA XRUN recovery #88

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8f299cd
[RFC]platform:bug fix: alsa xrun cause fw panic.
Jul 11, 2018
cda7019
[RFC]host:the host state must be PREPARE when stopped.
Jul 11, 2018
ec02d6c
[RFC]component:when xrun comes, component may be in prepare.
Jul 11, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion src/audio/component.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,8 @@ int comp_set_state(struct comp_dev *dev, int cmd)
break;
case COMP_TRIGGER_STOP:
case COMP_TRIGGER_XRUN:
if (dev->state == COMP_STATE_ACTIVE) {
if (dev->state == COMP_STATE_ACTIVE ||
dev->state == COMP_STATE_PREPARE) {

@plbossart plbossart Jul 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WTH?
If you are in PREPARE state you set the component to PREPARE? I call this a no-op...

@ghost ghost Jul 13, 2018 •
edited by ghost
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

conform with the previous RFC changed in src/audio/host.c

dev->state = COMP_STATE_PREPARE;
} else {
trace_comp_error("CEs");
Expand Down
2 changes: 1 addition & 1 deletion src/audio/host.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -740,7 +740,7 @@ static int host_stop(struct comp_dev *dev)
/* reset elements, to let next start from original one */
host_elements_reset(dev);

dev->state = COMP_STATE_PAUSED;
dev->state = COMP_STATE_PREPARE;

@plbossart plbossart Jul 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is really odd. You will end-up with different states in different components, see e.g. the SSP dai code where the component are set to PAUSED.
Does this even work?

@ghost ghost Jul 13, 2018

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think when the component is truly paused, it should be paused state.
but if the command is stop. we have to set it prepare state to ready for the next start comes.
that makes sense.

return 0;
}

Expand Down
12 changes: 12 additions & 0 deletions src/ipc/handler.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -449,6 +449,18 @@ static int ipc_stream_trigger(uint32_t header)
trace_error_value(ipc_cmd);
}

/* when stop 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.
*/
if (cmd == COMP_TRIGGER_STOP) {
ret = pipeline_prepare(pcm_dev->cd->pipeline, pcm_dev->cd);

@plbossart plbossart Jul 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that looks quite questionable. it's rather when you start that you should make sure things are prepared, no?

@ghost ghost Jul 13, 2018

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes effect similar like the pipeline XRUN recover process.
you can refer to the pipeline_xrun_recover() to understand the logic.
without prepare, the firmware will hit XRUN again when start command comes.

@ghost ghost Jul 13, 2018

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I make a stupid typo error, the Line459 should be:
ret = pipeline_prepare(pcm_dev->pipeline, pcm_dev->pipeline->source_comp);
I will update it after back office.

if (ret < 0)
trace_ipc_error("eR1");
}

return ret;
}

Expand Down