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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
