Just posted this same text on GitHub: https://github.com/apache/nuttx/issues/9127#issue-1687069010.
Content copied here for those that don't go there. ------------------- I have been investigating poor MTD performance with a GD25 memory on SPI0 of a SAMA5D27 processor. Using LittleFS, dd was showing 37KB/s transfer speeds. I ruled out LittleFS - SmartFS was even slower. The memory is set to run at 50MHz, but I was seeing only 10MHz, and long delays between transfers. looking at arch/arm/src/sama5/sam_spc.c it seems the SPI interface is hard coded to be deliberately slow: 1) SCBR (Serial Clock Bit Rate) forced to have a minimum value of 9, when the datasheet says 1 should be the minimum 2) DLYBS (Delay from NPCS going active to first valid clock) forced to be 2us 3) DLYBCT(Delay between 2 consecutive transfers) forced to be 5us 4) SPI clock defaulting to using main clock (164MHz) whereas it could use the Peripheral Clock (492MHz) which limits the resolution of the actual frequency realisable Changing these to the fastest allowable values results in a huge improvement in transfer speed - it's now 263KB/s. BUT...is there a good reason why these very big values have been chosen? Should they not be configurable rather than hard coded, even? I am aware there are other processors in the SAMA5 family (i.e. SAMA5D3 and SAMA5D4) so input from anyone who knows those would be welcomed, along with any general observations and suggestions on the best way to improve this? As an aside, DMA doesn't work for the SAMA5D2 SPI - it uses "XDMAC" not "DMAC" so Kconfig settings get disabled and the driver never works out the right DMA setup (which would be wrong for this device anyway!). I am very happy to work on the fix and a PR after some feedback.
