i.MX93 SAI1 TX FIFO errors

[wirelessguy]

Platform
Board: i.MX93 EVK; /sys/devices/soc0/soc_id=i.MX93,
/sys/devices/soc0/revision=1.1. Package marking/mask not yet recorded.
Linux: 6.12.20-lts-next-gdfaf2136deb2, PREEMPT, A55.
SAI1 at 0x443b0000, TX via 44000000.dma-controller-CH21.
SAI1 serial root: 40 MHz from VIDEO_PLL; 40 MHz BCLK, 1.25 MHz frame rate.
SAI3/WM8962 is Linux-owned and was idle for the reproductions below.
LMX2571 I2S FSK sink: signed 16-bit code in active slot, zero in other slot.
Constant code +8500 produces the expected +17 kHz RF offset.

Minimal Linux reproduction (M33 remoteproc offline)
Custom DTB exposes SAI1 as an ALSA playback device; SAI1 PCM card 0.
Static ALSA PCM: hw:0,0, S16_LE, 2 channels, 1,250,000 frames/s;
period 2,400 frames, buffer 19,200 frames. No Gaussian filter or other
real-time waveform generation. TX FIFO depth 32 words, TX DMA burst 8 words,
FIFO watermark 24. Static data: slot 0=8500, slot 1=0.
Command: python3 /root/cp7g_static_playback.py --device hw:0,0 --seconds 600
Latest result: 750,000,000 frames written in 599.958 s, ALSA xruns=0.
SAI1 FEF IRQ diagnostic: 1 episode, 9 IRQ entries over 2.685 ms.
First observed at monotonic uptime about 675.892537 s, approximately
7.16 s before playback stopped; not an end-of-stream drain event.

First-IRQ instrumentation (timings are after the hardware FEF assertion)
TCSR=0x90150c01; consecutive time reads=41 ns; handler work before first
TCSR read=209 ns; first TCSR regmap read=120,607 ns (return 0).
FEF W1C regmap write=241,007 ns (return 0), before detailed snapshot.
Post-ACK TFR0=0x00020001, read=242,799 ns.
Post-ACK eDMA CH21 first raw register read=241,423 ns; total CH21
snapshot time=487,722 ns. CH_CSR=0x80000005, CH_ES=0x00000000,
CH_INT=0x00000000, CH_SBR=0x00208003, CH_PRI=0x00000000.
The TFR0 and CH21 values were sampled after the acknowledgment, not at
initial FEF assertion. The long reads/writes cannot establish that they
caused the initial FIFO error; CH_ES=0 only says no channel error was
latched when sampled. The FEF is a hardware event despite ALSA xruns=0.

Independent simplified firmware reproduction
With Linux booted and ALSA capture idle, M33 code drove the same SAI1 TX
using a single self-linked eDMA CH21 TCD, constant +8500 / zero slots,
no major-loop callbacks, no foreground buffer refill, no Gaussian filter.
At 40 MHz BCLK, FIFO depth 32, watermark 24, DMA minor loop 16 bytes,
it stopped on SAI1 FEF after 216 s (Rev R). In the post-FEF fault snapshot,
CH21_ES=0 and DMA global ES=0; the TCD was still self-linked. Similar faults occurred
in later priority and internal-BCLK trials. A half-rate trial also failed.
Thus neither Python nor M33 waveform computation/refill is necessary to
reproduce the intermittent SAI1 FEF. Linux playback also fails with the
M33 offline. Probe loading and external wire length changes did not remove
the problem.

Additional observation
A burst-4 / watermark-28 Linux run had one FEF episode at uptime about
676.889 s on a separate boot; the latest burst-8 fault was at 675.893 s.
A system journal search around 670–682 s in the latest boot found no
logged activity. Similar uptime is suggestive only, not proof of a timer.

Questions for NXP
1. Is there a known i.MX93 rev 1.1 mask erratum or low-power/interconnect
condition that can delay SAI1 and eDMA CH21 register access and/or DMA
service by 100–250 us while SAI1 TX and its clocks are enabled?
2. What hardware status, clock-gating, interconnect, or eDMA traces can
identify the first missed SAI1 FIFO service request before FEF?
3. Does SAI1 TX FEF indicate any condition other than an actual FIFO
underrun in this asynchronous master configuration?
4. Are there documented SAI1/eDMA burst, watermark, or clock constraints
for continuous 40 MHz BCLK / 1.25 MHz stereo frame output on i.MX93?

Can provide custom DTB, Linux fsl_sai.c/h changes and static playback
script, M33 self-linked TCD source, full boot clock tree, and scope/RF data.

[JorgeCas]

Hello,

I apologize for the delay, please note that due to limited bandwidth during the holidays in China, the response may be delayed. Thank you for your understanding.

1. No, there are no erratum describing the behavior you are seeing in your design.

2. TCSR[FEF] means that an enabled transmit FIFO has an underrun error, it does not identify whether the cause was a lost DMA request.

3. No, just FIFO underrun.

4. This configuration is within the SAI switching specifications. Please share the modifications you made so we can review them for any noticeable issue that could be contributing to this behavior. Please note that driver modifications are not validated on our side.

Best regards.