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.

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

drivers: dai: sai: write some data into TX FIFO before start #72791

Merged
merged 1 commit into from
May 17, 2024

Conversation

LaurentiuM1234
Copy link
Collaborator

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.

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 <[email protected]>
@carlescufi carlescufi merged commit ae08206 into zephyrproject-rtos:main May 17, 2024
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants