RE: SAMA5(D2) SPI speed is restricted by the driver
>From: Tomek CEDRO >Sent: Friday, April 28, 2023 5:15 PM > >On Thu, Apr 27, 2023 at 5:27 PM Tim Hardisty wrote: >> (..) >> I have been investigating poor MTD performance with a GD25 memory on >SPI0 of a SAMA5D27 processor. >> (..) >> I am very happy to work on the fix and a PR after some feedback. > >I do not have this board / mcu to help testnig, but I guess better >efficiency and new features are highly welcome :-) > >Tim if that helps I can buy selected board for testing, I do not have >time to help with development though, sorry. > >-- I have my custom board and an SAMA5D2 explained eval board so should be OK, thanks. I just want to make sure there's no "good" reason for this before messing it all up! Thanks for taking the time to reply :)
Re: SAMA5(D2) SPI speed is restricted by the driver
On Thu, Apr 27, 2023 at 5:27 PM Tim Hardisty wrote: > (..) > I have been investigating poor MTD performance with a GD25 memory on SPI0 of > a SAMA5D27 processor. > (..) > I am very happy to work on the fix and a PR after some feedback. I do not have this board / mcu to help testnig, but I guess better efficiency and new features are highly welcome :-) Tim if that helps I can buy selected board for testing, I do not have time to help with development though, sorry. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: SAMA5(D2) SPI speed is restricted by the driver
On Thu, Apr 27, 2023 at 11:27 AM Tim Hardisty 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
SAMA5(D2) SPI speed is restricted by the driver
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.
