Re: [RFC] omap2-mcspi: periodic zero TX in target mode - debugging help needed

["Péter Ujfalusi" <peter.ujfalusi@gmail.com>]

Hi,

On 12/02/2026 17:53, Jean-Michel Hautbois wrote:
> Hi,
> 
> I'm seeing a puzzling issue with omap2-mcspi in target mode on AM64x
> and could use some help understanding what might be happening.
> 
> Here is my setup:
> - AM64x as SPI target, external controller at ~1 MHz, 1 Hz frame rate
> - Target mode, DMA enabled (k3-udma, not legacy EDMA)
> - Fixed 64-byte transfers (matches MCSPI FIFO depth)
> - Full-duplex, using spi_async() for continuous operation
> - Kernel 6.12.y (also tried mainline, same behaviour) + PREEMPT_RT
> 
> Periodically, MISO outputs all zeros instead of the prepared TX buffer.
> The pattern is surprisingly regular: every 42 or 43 transfers.
> If transfer #10 fails, then #52 or #53, #94 or #95, etc.
> 
> This number (~42) doesn't obviously match any power of 2 or buffer
> size I'm using, which makes it more puzzling.

Curiously matches with the answer to the ultimate question (THGG) ;)

> I have verified a few things:
> - TX buffer is correctly filled before spi_async() returns
> - Added debug check: buffer is NOT zeros at submit time when failure occurs
> - RX works fine (master data received correctly)
> - System is mostly idle (basic Yocto, systemd, no heavy load)
> - Logic analyser confirms: zeros on MISO, correct clock/CS from master
> - Forcing single CPU (maxcpus=1) does not change behaviour
> 
> This suggests the data is correctly prepared but doesn't make it to
> the FIFO in time. The issue seems to be in omap2-mcspi or k3-udma,
> not in my slave protocol driver.
> 
> DMA configuration:
> - Using k3-udma (AM64x UDMA subsystem)
> - Single DMA descriptor per transfer (not cyclic)
> - DMA-coherent buffers allocated with dma_alloc_coherent()
> 
> Questions:
> 1. Are there known timing constraints for target mode DMA that
>    could explain this periodic behaviour?
> 2. Could this be related to k3-udma descriptor recycling or
>    ring management around ~42 iterations?
> 3. Is there recommended tracing/debug I should enable to
>    investigate the DMA/FIFO timing?
> 4. Has anyone seen similar periodic failures in target mode?
> 
> I can provide more details, traces, or test patches if helpful.

I would enable all interrupts (channel 0 is the relevant for
non-provider mode) FULL/UNDERFLOW/EMPTY and see if McSPI itself reports
any starvation.

Iteration is number of one-shot transfers (of equal size or variable size?)

I cannot recall anything which would result such an issue, but the
consistency is more than interesting. Re-reading the TRM for SPI + PDMA
and BCDMA (or PKTDMA is servicing McSPI?) might give some clues.

> 
> Thanks for any pointers!
> Jean-Michel

-- 
Péter