Is your source buffer in external SDRAM? The one issue with DMA is that after each byte transfer, the DMA must first acquire a new value over SDRAM (no cache) and then write it to the RSPI IP block sitting on the peripheral bus. I figured that would make some latency between bytes, but maybe it takes longer than I assumed.
If you are using SDRAM for the source buffer, it would be interesting if you tried internal RAM for the source buffer instead (you could just hard code the address for testing). Internally, the R-Car Gen2 busses (and external memory interface) are way faster than RZ/A1. Chris -----Original Message----- From: Daniel Palmer [mailto:[email protected]] Sent: Thursday, August 04, 2016 2:59 PM To: Geert Uytterhoeven <[email protected]> Cc: Chris Brandt <[email protected]>; [email protected] Subject: Re: spi-rspi mixes DMA and PIO transfers causing PIO transfer to fail. On 5 August 2016 at 03:46, Geert Uytterhoeven <[email protected]> wrote: > Performance figures for reading from a QSPI FLASH driven at 24.375 MHz > on r8a7791/koelsch: > - Single: 1.1 Mbps PIO, 23 Mbps DMA > - Dual : 12.7 Mbps PIO, 48 Mbps DMA > - Quad : 13 Mbps PIO, 70 Mbps DMA Thanks for those numbers. I have something to aim for now. :) What I'm seeing on my logic analyser with the bus at 10MHz is 8 clocks taking ~500ns, ~1700ns of idle and then 8 more clocks. spi-rpi doesn't seem to set any of the registers for adding in delays so I guess it's to do with the DMA controller. Cheers, Daniel
