[PATCH 03/32] spi: dw: Fix driving MOSI low while recieving

[Serge Semin]

On Mon, Nov 09, 2020 at 02:14:22PM +0000, Mark Brown wrote:
> On Mon, Nov 09, 2020 at 08:47:10AM -0500, Sean Anderson wrote:
> > On 11/9/20 8:29 AM, Mark Brown wrote:
> 
> > > In this case it also looks like the controller hardware requires
> > > transmit data and therefore should be setting SPI_MUST_TX and just
> > > removing the in driver default anyway, though that will have no effect
> > > one way or anther on the issue you're seeing.
> 

> > There is a recieve-only mode, but it is not used by this driver. Perhaps
> > it should be.
> 
> I'd expect it'd perform better, especially on systems that are
> apparently struggling for CPU bandwidth like yours seems to.

Well, it might seem a good idea to use that mode, but there are multiple problems
you may get in implementing it.

First of all the Receive-only mode is having a limited number bytes to receive
at once. It's just 64KB. So in order to implement it you'd need to split the
bigger transfers up, and feed the DMA engine with smaller chunks one-by-one.

Secondly the Receive-only mode will make the DW SSI controller to constantly receive
the data from the SPI bus and to put it into the Rx FIFO. So your DMA engine will
have to keep up with extracting the data from there on time, otherwise you'll
end up with Rx FIFO overflow error eventually. The problem will be actual for the
DMA engines/system buses, which are slower than the SPI bus speed, second for the
DMA engines with no hardware accelerated LLP traversal support (like on our DWC DMA
controller). The second problem can be also fixed by splitting the transfers up as
it has been already implemented in the spi-dw-dma.c. But the first problem can't be
fixed, but just workarounded by limiting the SPI bus frequency so the DMA engine
would keep up with incoming data traffic.

-Sergey

> 
> > > Please also try to avoid the use of master/slave terminology where
> > > reasonable, controller and device tend to work for SPI (though MOSI/MISO
> > > are going to be harder to shift).
> 
> > Here I use it to draw distinction between the SPI master and the SPI
> > slave, which are both devices in different contexts. 
> 
> If you find the use of device to refer to the device being controlled
> confusing consider also using something like client device instead,
> there's a number of ways to do it (there's a list in Documentation IIRC).