Re: Patch to parameterize DMA_MIN_BYTES for omap2-mcspi

[Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>]

On 03/19/2015 03:16 PM, Greg Knight wrote:
> Will refer to that documentation and update the SPI docs before resubmitting.
> 
> Re; Threshold of 160 is artificial: Believe me, I am more than aware
> of this. SPI runs in any speed from low kHz to multi MHz. The only
> reason I can fathom for having such a high DMA_MIN_BYTES is to
> facilitate high-speed low-volume communication (eg read one byte at a
> time from userspace without buffering.) The reason I'm looking at this
> at all is because we're doing low-speed low-volume communication, for
> which the burn in PIO mode causes severe performance degradation.
> Internally we'd changed it to 20, but I might try 8. I originally
> tried 0, but observed poor behavior for our use cases. DMA_MIN_BYTES
> at 8 would be sensible for our application, but at 160 it is not.
> 
> How about moving the speed to the spidev DT nodes?

The issue is that: "The device tree is a data structure for describing hardware"
DMA_MIN_BYTES is a software parameter. To be specific, it is Linux software
parameter applicable only to spi-omap2-mcspi.c driver.

I think the best thing we could do is to calculate the DMA_MIN_BYTES in the
driver based on the SPI speed. Something which will give ~160 in the speed in
which the wl driver is used and something which works best in your setup in
the speed you are using the SPI bus.
The best way is to give some msec as a limit. If the transfer would take more
then X msec on the bus to be transferred, we will use DMA, if it is less than
that we fall back to PIO.
Yes, the CPU speed is not taken into account, but IMHO the bus speed is more
important.

What do you think? Will this work for you?

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html