SPI with DMA safe to call DMA API from ISR? (NXP LPSPI)

[asteriskSF]

I noticed a performance issue in a project I'm working on that involves SPI with DMA. The NXP LPSPI driver sends a semaphore from the DMA callback to resume the thread processing for every buffer in the SPI operation. This causes a context switch with 6-9 microseconds of delay. When using the ISR-based SPI, the next operation is initiated directly from the callback without another context switch to resume the blocked transfer. The DMA thread processing is essentially the same as the ISR-based processing, but it must also call the DMA driver api to update the buffers.

In general is it safe to call a DMA driver API from a DMA callback which is presumably in an ISR?

[DerekSnell]

Hi @asteriskSF , sorry for the delay.

And sorry that I need more details from you to look into this further. First, what semaphore are you referring to in the DMA callback? I looked at the LPSPI driver in spi_mcux_lpspi.c, and do not see a semaphore referenced there. Unless you are referring to the semaphore in spi_context.h. But that is part of Zephyr's driver, and is common for all SPI implementations in Zephyr.

And can you be more specific about where a DMA driver API is called from the DMA callback? Also, what thread are you referring to when you say "DMA thread processing"?

Thanks

[asteriskSF]

from the caller's thread, wait_dma_rx_tx_done calls the spi_context_wait_for_completion which waits for a semaphore:
if (k_sem_take(&ctx->sync, timeout))

spi_mcux_dma_callback (probably in ISR) calls spi_context_complete which sets sync->status and gives the semaphore:
ctx->sync_status = status;
k_sem_give(&ctx->sync);

I'm not worried about the semaphore interaction itself, but the context switch back to the calling task for each DMA is a performance bottleneck.

I am considering updating the DMA buffers from within the ISR, essentially doing the stuff in the while loop after the comment which says:

Send each spi buf via DMA, updating context as DMA completes

This would avoid the context switching until the last DMA has completed. The DMA api calls that I'm concerned about are the dma_start(...) and dma_config(...) which are called from within the while loop. These are generic DMA driver API's that lookup the underlying DMA functions through the device's API.