RE: SAMA5(D2) SPI speed is restricted by the driver

[TimH]

>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

[Tomek CEDRO]

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

[Nathan Hartman]

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