{{ message }}
hda-dma: Fix HDA DMA position regs going out of sync with w_ptr/r_ptr#10013
Merged
Conversation
lyakh
reviewed
May 16, 2025
Contributor
Author
The HDA DMA hardware keeps track of data in the DMA buffer using hardware Read and Write Position registers. The software uses the struct audio_stream with w_ptr and r_ptr for a similar purpose. If the software w_ptr and r_ptr do not point to the same location as the hardware Write and Read Position registers, the problem occurs. Such desynchronization happens upon a pipeline reset. The dma_buffer is freed during a reset in dai-zephyr or host-zephyr and reallocated in prepare() after the pipeline resume. The reallocated dma_buffer has w_ptr and r_ptr set to NULL, while the hardware HDA DMA Read and Write Position registers retain their values. If, for example, in the DAI playback case, the difference between the Write Position register and w_ptr is more than one period, the problem could easily go unnoticed as the hardware simply copies older data. In case where the difference between the Write Position and w_ptr is more than 0 but less than one period, the DMA copies part of the new data and part of the old data, resulting in glitches. This fix ensures that the software w_ptr and r_ptr stay in sync with the hardware HDA DMA Write and Read Position registers. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
bbe1490 to
f253491
Compare
kv2019i
approved these changes
May 16, 2025
kv2019i
left a comment
Collaborator
There was a problem hiding this comment.
Did you see this in some existing test case? Do you think we should cherry-pick this to v2.13?
Contributor
Author
tmleman
approved these changes
May 19, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 HDA DMA hardware keeps track of data in the DMA buffer using hardware Read and Write Position registers. The software uses the struct audio_stream with w_ptr and r_ptr for a similar purpose. If the software w_ptr and r_ptr do not point to the same location as the hardware Write and Read Position registers, the problem occurs.
Such desynchronization happens upon a pipeline reset. The dma_buffer is freed during a reset in dai-zephyr or host-zephyr and reallocated in prepare() after the pipeline resume. The reallocated dma_buffer has w_ptr and r_ptr set to NULL, while the hardware HDA DMA Read and Write Position registers retain their values.
If, for example, in the DAI playback case, the difference between the Write Position register and w_ptr is more than one period, the problem could easily go unnoticed as the hardware simply copies older data. In case where the difference between the Write Position and w_ptr is more than 0 but less than one period, the DMA copies part of the new data and part of the old data, resulting in glitches.
This fix ensures that the software w_ptr and r_ptr stay in sync with the hardware HDA DMA Write and Read Position registers.