On Fri, May 29, 2020 at 11:12:04AM +0300, Serge Semin wrote:

On Fri, May 29, 2020 at 10:55:32AM +0300, Andy Shevchenko wrote:

quoted

On Fri, May 29, 2020 at 7:02 AM Serge Semin
[off-list ref] wrote:

quoted

Even if DMA transactions are finished it doesn't mean that the SPI
transfers are also completed. It's specifically concerns the Tx-only
SPI transfers, since there might be data left in the SPI Tx FIFO after
the DMA engine notifies that the Tx DMA procedure is done. In order to
completely fix the problem first the driver has to wait for the DMA
transaction completion, then for the corresponding SPI operations to be
finished. In this commit we implement the former part of the solution.

Note we can't just move the SPI operations wait procedure to the DMA
completion callbacks, since these callbacks might be executed in the
tasklet context (and they will be in case of the DW DMA). In case of
slow SPI bus it can cause significant system performance drop.

quoted

I read commit message, I read the code. What's going on here since you
repeated xfer_completion (and its wait routine) from SPI core and I'm
wondering what happened to it? Why we are not calling
spi_finalize_current_transfer()?

We discussed that in v4. You complained about using ndelay() for slow SPI bus,
which may cause too long atomic context execution. We agreed. Since we can't wait
in the tasklet context and using a dedicated kernel thread for waiting would be too
much, Me and Mark agreed, that

even if it causes us of the local wait-function
re-implementation the best approach would be not to use the generic
spi_transfer_wait() method, but instead wait for the DMA transactions locally
in the DMA driver and just return 0 from the transfer_one callback indicating
that the SPI transfer is finished and there is no need for SPI core to wait. As
a lot of DMA-based SPI drivers do.

The above is missed in the commit message.

If you don't understand what the commit message says, just say so. I'll
reformulate it.

See above. A bit of elaboration would be good. Thank you!

-- 
With Best Regards,
Andy Shevchenko