ae082064ff
While running the following command: aplay ... | arecord ... multiple times, it was discovered that the SAI transmit FIFO goes into underrun. This only happened in the beginning, a few BCLK cycles after unmasking the transmit data line. With the following flow: 1) Trigger start on RX a) Do TX and RX software reset b) Enable RX FIFO error interrupt c) Enable RX DMA requests d) Enable receive data line e) Enable transmitter f) Enable receiver ..... some time has passed ..... 2) Trigger start on TX a) Enable DMA requests b) Enable transmit data line and configuration in mind: 1) RX is SYNC with TX 2) TX is ASYNC 3) Each FSYNC edge is 32-bit wide 4) Each frame contains 2 32-bit words this points to the following possibilites: 1) The transmitter is enabled so close to the start of a new frame that even though the DMA requests are asserted, the DMAC doesn't have enough time to service them until the module goes into underrun => the timing is bad. 2) The transmitter is enabled somewhat close to the start of a new frame such that the DMAC is not fast enough to service the module until it goes into underrun => DMAC is too slow AND the timing is bad. Although the exact cause was not pinpointed, this patch aims to fix the problem by writing a frame's worth of 0s in the transmit FIFO. This way, even if we're dealing with scenario 1) or 2), the DMAC has plenty of time to perform the transfer (i.e: a frame), thus avoiding the underrun. Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com> |
||
---|---|---|
.. | ||
intel | ||
nxp | ||
CMakeLists.txt | ||
Kconfig |