hda-dma: Fix HDA DMA position regs going out of sync with w_ptr/r_ptr #10013
Conversation
serhiy-katsyuba-intel
requested review from
dbaluta,
kv2019i,
lbetlej,
lgirdwood,
mmaka1 and
plbossart
as code owners
|
Failures in CI related to MTL and TGL. Zephyr's GPDMA does not return write_position and read_position in dma_status :( Temporarily switching to draft. Update: Now fixed with new version. |
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>
serhiy-katsyuba-intel
force-pushed
the
dma_buf_sync
branch
from
bbe1490 to
f253491
Compare
serhiy-katsyuba-intel
changed the title
kv2019i
left a comment
kv2019i
left a comment
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?
Yes. Bug report: https://hsdes.intel.com/appstore/article/#/18041236600 (Sorry, it's Intel's internal link). |
4 participants
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.