Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Piotr Bugalski <bugalski.piotr@gmail.com>
Date:   Thu, 28 Jun 2018 14:02:19 +0200 (CEST)
To:     Tudor Ambarus <tudor.ambarus@microchip.com>
cc:     Piotr Bugalski <bugalski.piotr@gmail.com>,
        Boris Brezillon <boris.brezillon@bootlin.com>,
        Mark Brown <broonie@kernel.org>, linux-spi@vger.kernel.org,
        David Woodhouse <dwmw2@infradead.org>,
        Brian Norris <computersforpeace@gmail.com>,
        Marek Vasut <marek.vasut@gmail.com>,
        Richard Weinberger <richard@nod.at>,
        linux-mtd@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Nicolas Ferre <nicolas.ferre@microchip.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Cyrille Pitchen <cyrille.pitchen@microchip.com>,
        Piotr Bugalski <pbu@cryptera.com>
Subject: Re: [RFC PATCH 1/2] spi: Add QuadSPI driver for Atmel SAMA5D2
In-Reply-To: <1d736934-b3e7-7b23-0f34-1d22d36b2b18@microchip.com>
Message-ID: <alpine.DEB.2.20.1806281352590.22837@carbonite>
References: <20180618162124.21749-1-bugalski.piotr@gmail.com> <20180618162124.21749-2-bugalski.piotr@gmail.com> <20180621233321.0f25f572@bbrezillon> <alpine.DEB.2.20.1806220719190.21824@carbonite> <20180622093905.62a3b936@bbrezillon>
 <455adb76-530a-1fd5-303c-cfa158ad7870@microchip.com> <alpine.DEB.2.20.1806270940500.32198@carbonite> <1d736934-b3e7-7b23-0f34-1d22d36b2b18@microchip.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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