public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: bugalski.piotr@gmail.com (Piotr Bugalski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/2] spi: Add QuadSPI driver for Atmel SAMA5D2
Date: Thu, 28 Jun 2018 14:02:19 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1806281352590.22837@carbonite> (raw)
In-Reply-To: <1d736934-b3e7-7b23-0f34-1d22d36b2b18@microchip.com>


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

  reply	other threads:[~2018-06-28 12:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 16:21 [RFC PATCH 0/2] New QuadSPI driver for Atmel SAMA5D2 Piotr Bugalski
2018-06-18 16:21 ` [RFC PATCH 1/2] spi: Add " Piotr Bugalski
2018-06-19 15:15   ` Mark Brown
2018-06-20 14:31     ` Piotr Bugalski
2018-06-21 21:33   ` Boris Brezillon
2018-06-22  5:57     ` Piotr Bugalski
2018-06-22  7:39       ` Boris Brezillon
2018-06-26 14:44         ` Tudor Ambarus
2018-06-27  7:52           ` Piotr Bugalski
2018-06-28  8:37             ` Tudor Ambarus
2018-06-28 12:02               ` Piotr Bugalski [this message]
2018-06-18 16:21 ` [RFC PATCH 2/2] dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation Piotr Bugalski
2018-06-20 14:47   ` Boris Brezillon
2018-06-21 10:56     ` Piotr Bugalski
2018-06-20 14:54 ` [RFC PATCH 0/2] New QuadSPI driver for Atmel SAMA5D2 Boris Brezillon
2018-06-21 10:52   ` Piotr Bugalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1806281352590.22837@carbonite \
    --to=bugalski.piotr@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox