Hi,

I'm working with version 3.14.25(-rt22) on a BeagleBoneBlack and want to
use the SPI (SPIDEV) interface to poll a sensor at a high rate. Because
the transfer mode defaults to PIO for small data transfers below the
DMA_MIN_BYTES threshold of 160 bytes, I set DMA_MIN_BYTES to 1 in order
to always use of the DMA interface to lower CPU load.
Having used DMA transfers for a while I noticed that my userspace
program ended up in an uninterruptible state sooner or later. I traced
it down to the ioctrl(...) call to the SPIDEV interface.
Tracing the kernel to find out what happened there I found out that for
some transfer both the "omap2_mcspi_rx_callback()" and
"omap2_mcspi_tx_callback()" functions have not been called back, so the
driver was stuck at "wait_for_completion(&mcspi_dma->dma_rx_completion)"
in function "omap2_mcspi_rx_dma()".

Out of the blue I ran the associated spi kernel thread with a higher
realtime priority (setting spi master property rt = true)  and did not
see any missing callbacks anymore (see
001-omap2-mcspi-set-rt-flag.patch). Actually a RTPRIO higher than the
kernel interrupt threads (>50) was enough to not miss any callback calls.
Well, this seems to be some kind of race condition, but I finally
couldn't find out where to look for the callback problem, maybe even in
the EDMA module?

Something else I found out was that the order in DMA handling is
important for the problem to occur.
In "omap2_mcspi_rx_dma()" the RX DMA handling looks like this:

    .....
    dma_async_issue_pending(mcspi_dma->dma_rx);
    omap2_mcspi_set_dma_req(spi, 1, 1);

    wait_for_completion(&mcspi_dma->dma_rx_completion);
    dma_unmap_single(mcspi->dev, xfer->rx_dma, count,
             DMA_FROM_DEVICE);
    ....

Whereas the activation and "wait-for-callback" for TX DMA is split into
function "omap2_mcspi_tx_dma()" (DMA activation) and
"omap2_mcspi_txrx_dma()" (wait-for-callback).
When I bring together activation and "wait-for-callback" for TX DMA into
function "omap2_mcspi_tx_dma()" (see 002-omap2-mcspi-change-
dma-transfer.patch) I also don't see missed
callbacks, even at very low RTPRIOs.

Does that make sense to anybody? This problem also occurs on 3.14.25
without PREEMPT patch applied.
See attached also my kernel config.

Thanks
Philipp