Skip to content
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

audio: dai-zephyr: Do not reset the DMA buffer cursor for HD-DMA on T… #8995

Merged
merged 1 commit into from
Apr 3, 2024
Merged

audio: dai-zephyr: Do not reset the DMA buffer cursor for HD-DMA on T… #8995

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
6 changes: 5 additions & 1 deletion src/audio/dai-zephyr.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1141,8 +1141,12 @@ static int dai_comp_trigger_internal(struct dai_data *dd, struct comp_dev *dev,
* leading to the DMA copying stale data due to
* dma_status() stopping dai_common_copy() from
* updating the data.
*
* Only applies to non HD-DMA links as HD-DMA read/write pointer
* is not reset during stop/config/start
*/
audio_stream_reset(&dd->dma_buffer->stream);
if (!(dd->dai->dma_caps & DMA_CAP_HDA))
audio_stream_reset(&dd->dma_buffer->stream);
Copy link
Collaborator

Choose a reason for hiding this comment

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

@LaurentiuM1234 @dbaluta With this fixup in place, this does not look like a solid design anymore. Either SOF can assume something about Zephyr DMA driver behaviour, or it cannot. It does sound like instead of audio_stream_reset, SOF should synchronize its view of DMA driver state (either at start or stop) and we could again have code that works for all (then it's upto DMA drivers how they behave for pause/reset).

Not blocking this PR as this fixes a rather nasty bug with Intel HDA devices, but I think this needs further work. The HW details should be handled on Zephyr side and SOF code should be agnostic.

Copy link
Contributor

Choose a reason for hiding this comment

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

ACK. Just curious, why do we need the dma_stop() and dma_config() operations on release? If I recall correctly, an alternative to 9831a9d was to just, well, not do those, which worked on NXP platforms at least? This would have been another way of keeping the buffers consistent with each other (i.e: SOF view and DMA view)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@LaurentiuM1234, HD-DMA zephyr driver does not support dma_resume(), other than that, I don't know why we do the stop/start here.. We do clear the buffer, so it would kind of make sense to stop/start the DMA, but why we clear the buffer on pause/resume? I don't know.


/* only start the DAI if we are not XRUN handling */
if (dd->xrun == 0) {
Expand Down
Loading