Re: [PATCH V2 5/6] spi: bcm2835: make the lower limit for dma mode configurable

[Lukas Wunner <lukas@xxxxxxxxx>]

On Tue, Apr 23, 2019 at 08:15:12PM +0000, kernel@xxxxxxxxxxxxxxxx wrote:
> Under some circumstances the default 96 byte limit is not optimal.
> 
> The polling and interrupt mode of the spi-bcm2835 controller exhibit a
> 1 idle clock cycle which is missing when using DMA.
> 
> So when transferring a longer spi_transfer to some low spec MCU devices
> without SPI FIFOs like a ATMega it means that the SPI has to get reduced
> by a factor of 2 or more when using DMA mode compared to using PIO modes
> to give the MCU enough time to handle the incoming spi byte and prepare
> the next byte to get delivered - these extra 4+ CPU cycles that the idle
> spi clock is providing allows bigger transfers to work at faster speeds
> (assuming highly optimized MCU code).
> So forcing the transfer to use PIO mode to geth this behaviour for
> longer transfers is of advantage.
> 
> The oposite is true when (ab)using the spi MOSI line alone to control a
> WS2812B RGB LED stripe, where the DMA mode makes it possible to use the
> MOSI lines alone (with correct encoding) to control the LED.
> 
> So both extremes have there use cases and with this patch we allow to
> control the policy on a controller wide basis.
> 
> Right now we only allow to control the limit on a controller wide basis,
> but in the future it may be possible to configure this on a per spi_device
> basis.

Indeed I'd prefer if another bit is added to "mode" in struct device
to represent the need for another clock cycle in-between bytes.
The SPI core could then reduce the clock speed based on this flag
and the problem would be solved for everyone.

Influencing this behavior with a module parameter feels a bit like a
kludge and I fear may stay indefinitely even if a better solution
is implemented later.

Thanks,

Lukas