On Fri, 2019-03-08 at 12:16 +0000, Mark Brown wrote: > On Fri, Mar 08, 2019 at 12:55:52AM +0000, Trent Piepho wrote: > > On Thu, 2019-03-07 at 10:30 +0000, Mark Brown wrote: > > > On Wed, Mar 06, 2019 at 06:57:12PM +0000, Trent Piepho wrote: > > > > High speed receive operations may be less likely to have issues > > > > with > > > > FIFO overflow when using DMA than when using PIO. > > > > The eCSPI appears to insert a 4 bit pause after each word in DMA > > > > mode, > > > > not done in PIO mode, which can make DMA transfers 50% slower than > > > > PIO. > > > Wow, that's... innovative. If that's the case can't the decision > > > function for switching to DMA be tweaked to take into account slave > > > mode operation instead? > > Do you mean slave mode as in the imx being the spi slave and the > > external device the master? That's not being used here. > > Sorry, not sure where I got that from. Must've just switched from > another mail talking about that or something. The point still stands I have another patch out for imx spi, to fix a buffer overflow related to rx fifo flushing needed in spi slave mode. > though, can't we handle this by adjusting the decision function? Though > there's an unfortunate system load/performance tradeoff... If we can't > do that then I think a runtime control with a device property in sysfs > would be a good idea as well. The module parameter is writable, so it is a runtime control in sysfs, /sys/module/spi_imx/parameters/use_dma. It's also settable on boot via command line "spi_imx.use_dma=0". Very handy if you have a kernel driver that will use spi on init, which a custom sysfs device attr wouldn't address, since it couldn't be set. A device tree attribute could be used, but this is Linux configuration, not hardware layout, and shouldn't go into the device tree. I also found another reason to not use DMA: qemu can't emulate imx SPI when it uses DMA. It works for PIO. So being able to add spi_imx.use_dma=0 to the kernel command line when booting the kernel in qemu is very handy!