> On 12.04.2019, at 13:16, Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Fri, Apr 12, 2019 at 12:09:34PM +0100, Mark Brown wrote: >> On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote: >>> On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote: >>>> I *think* we managed to fix all the architectures to at least stub out >>>> the DMA interfaces, it's such a pointless thing to have conditional - >>>> it really only makes a difference for build coverage. >> >>> My point was that the call to spi_split_transfers_maxsize() shouldn't >>> be called on non-DMA-capable platforms in the first place (because it's >>> DMA-specific). >> >> It's not a DMA specific problem - there can be SPI controller >> limitations on transfer sizes too. > > The call does pass in ctlr->max_dma_len though, so is clearly motivated > by a DMA limitation. The limitation is in this register: BCM2835_SPI_DLEN Where the bcm2835-SDK (Brcm_Android_ICS_Graphics_Stack.tar.gz)defines: bit 0-15 for DLEN See transformed data at: https://github.com/msperl/rpi-registers/blob/master/md/Region_SPI.md Or the Arm Periperial Document on page 156 with regards to DLEN register. This is where the DMA length limit comes from - so it is NOT really DMA block related but SPI block related. More specifically to DMA requests are only triggered when this counter is > 0. That is unless the Documentation has another errata and more bits are actually allowed. Martin