Hi Tudor,
On Thu, 28 Jun 2018, Tudor Ambarus wrote:
Hi, Piotr,
On 06/27/2018 10:52 AM, Piotr Bugalski wrote:
General things to consider for the limitation in performance:
- is the serial flash memory operating in Quad SPI?
Yes, I've checked signal using logic analyzer, data is transferred using
all four lines.
- QSCLK should be as high as possible
Sure, but when we are using lower frequency CPU impact should be
negligible while efficiency is crap on every speed.
- transfer delays - I checked them, they have default values, we should be good.
- use DMA, as you suggested
I don't understand one thing. While CPU is not busy and during my tests
100% of CPU can be used for communication, efficiency is still very low.
Why DMA has such impact?
It is very interesting to observe signals using logic analyzer.
When CPU is used for communication, there are long delays after
every byte transferred. These delays are much longer than it should be only because of writing next value by CPU.
Are those consecutive transfers (same peripheral without removing chip select)?
The delays between consecutive transfers can be set just in SPI mode. It would
be strange to see this kind of delays in serial memory mode.
Yes, it's just single block transfer so no CS changes occurs.
I find this delays strange also, but I have no idea how to avoid them.
The same behaviour exists even when DMA is used in APB mode (write
to registers). Only using SMM with DMA helps.
I tried to change SPI frequency. If delay were CPU related,
delay time should stay the same. Unfortunately results were different -
lowering SPI freqency extends delay time.
If QSCK is less than f-perif-clock/2, then setting DLYBS to 1 will shorten the
DLYBS delay, but this is peanuts.
I have DLYBS, DLYCS and DLYBCT set to zeros. I can try DLYBS=1 if
you wish.
Thanks,
ta
Using DMA makes these delays to disappear, but how to acheive CPU
communication without delays?
Thank you for comments,
Piotr
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
