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

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

[Jean-Michel Hautbois]

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.

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.

Thanks for any pointers!
Jean-Michel

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

[Péter Ujfalusi]

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