On Thu, Apr 27, 2023 at 11:27 AM Tim Hardisty <t...@hardisty.co.uk> wrote:
> 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 don't work with this architecture so take with a grain of salt, but my guess is that these settings were based on the board used at the time it was implemented. Perhaps whoever implemented it didn't need the additional logic to select interface speeds etc. 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. > > Cheers Nathan
