[PATCH 3/8] spi: davinci: limit the transfer size if DMA enabled

Sekhar Nori nsekhar at ti.com
Tue Feb 14 07:29:56 PST 2017


On Tuesday 14 February 2017 04:57 PM, Frode Isaksen wrote:
> 
> 
> On 13/02/2017 06:59, Sekhar Nori wrote:
>> + Peter
>>
>> On Friday 10 February 2017 08:59 PM, Frode Isaksen wrote:
>>> Limit the transfer size to 20 scatter/gather pages if
>>> DMA is enabled.
>>> The eDMA DMA engine is limited to 20 SG entries in one DMA
>>> transaction. If this number is exceeded, DMA receive fails.
>>> This error occurs with large vmalloc'ed buffers.
>> This needs more explanation because there is support available in edma
>> driver for long SG lists by breaking them down into transfers using 20
>> PaRAM entries at a time. If thats not working for you, that needs
>> further debug.

> The SPI controller has a FIFO of only 1 word, so at 1Mbps, filling the
> FIFO will take only 8us. Handling the DMA interrupt and re-programming
> the PaRAM entries takes much longer than that. At 1Mbps, about 50 bytes
> is lost on Rx, @ 2Mbps 100 bytes and @ 5Mbps about 260 bytes hinting
> towards a time setting up a new DMA transfer > 400us. If the Tx and Rx
> buffers are identically aligned there are no errors, because the
> re-programming of the Tx and Rx PaRAM entries happens at the same time.
> I have also verified this with a scope. In the Tx direction, there is a
> pause in the transfer of 600us after the 20th SG entrey (when setting up
> new PaRAM entries). Since setting up Rx PaRAM is identical, this shows
> that breaking down the transfer is not working in the Rx direction for
> SPI caused by the relative high bit rate and small FIFO.

SPI is synchronous transfer so it does not need a large FIFO. If DMA is
not able to replenish the TX shift register, the master should hold the
clock until the time it is ready with data. On the scope do you see
master continuing to pulse the clock while it is waiting for data to
arrive from DMA to its TX shift register ? That should not be happening.

Thanks,
Sekhar



More information about the linux-arm-kernel mailing list