Repository navigation
ASoC: SOF: reset DMA state in prepare - #1049
Merged
ranj063 merged 3 commits intoJul 5, 2019
Merged
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The PCM status for hw_ptr and appl_ptr is reset at prepare
by ALSA core (see snd_pcm_do_prepare()).
When application goes through SUSPEND/STOP->PREPARE->START
cycle, we should always reprogram the SOF device DMA to start
zero offset. Otherwise first call to pcm pointer() will
return an invalid hw_ptr and application may immediately
observe XRUN status, unless "start_threshold" SW parameter
is set to maximum value by the application.
In current SOF, prepare() implementation in SOF core only
reprograms the HW in case system is resuming from S3. So
we are clearly not following ALSA semantics here.
In this RFC patch, enforce correct DMA programming by
freeing the HW params at each stop. This does more than
is needed, but ensures aligned start after prepare() is called.
Fixes #1062 #1057