Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <4b8b629b-62f8-8e0d-5de2-9020a955f0e2@linaro.org>
Date:   Tue, 28 Mar 2023 10:36:40 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Subject: Re: [PATCH 5/8] ARM: dts: at91-sama5d27_wlsom1: Set sst26vf064b SPI
 NOR flash at its maximum frequency
Content-Language: en-US
To:     Nicolas Ferre <nicolas.ferre@microchip.com>, broonie@kernel.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        alexandre.belloni@bootlin.com, claudiu.beznea@microchip.com
Cc:     linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mtd@lists.infradead.org
References: <20221117105249.115649-1-tudor.ambarus@microchip.com>
 <20221117105249.115649-6-tudor.ambarus@microchip.com>
 <a6fe77b6-4ff4-3c91-0c67-a9da5a638e7b@microchip.com>
From:   Tudor Ambarus <tudor.ambarus@linaro.org>
In-Reply-To: <a6fe77b6-4ff4-3c91-0c67-a9da5a638e7b@microchip.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 3/28/23 09:51, Nicolas Ferre wrote:
> Hi Tudor,

Hi!

> 
> On 17/11/2022 at 11:52, Tudor Ambarus wrote:
>> sama5d27-wlsom1 populates an sst26vf064b SPI NOR flash. Its maximum
>> operating frequency for 2.7-3.6V is 104 MHz. As the flash is operated
>> at 3.3V, increase its maximum supported frequency to 104MHz. The
>> increasing of the spi-max-frequency value requires the setting of the
>> "CE# Not Active Hold Time", thus set the spi-cs-setup-ns to a value of 7.
>>
>> The sst26vf064b datasheet specifies just a minimum value for the
>> "CE# Not Active Hold Time" and it advertises it to 5 ns. There's no
>> maximum time specified. I determined experimentally that 5 ns for the
>> spi-cs-setup-ns is not enough when the flash is operated close to its
>> maximum frequency and tests showed that 7 ns is just fine, so set the
>> spi-cs-setup-ns dt property to 7.
>>
>> With the increase of frequency the reads are now faster with ~37%.
>>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>> ---
>>   arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
>> b/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
>> index 83bcf9fe0152..20caf40b4755 100644
>> --- a/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
>> +++ b/arch/arm/boot/dts/at91-sama5d27_wlsom1.dtsi
>> @@ -220,7 +220,8 @@ qspi1_flash: flash@0 {
>>           #size-cells = <1>;
>>           compatible = "jedec,spi-nor";
>>           reg = <0>;
>> -        spi-max-frequency = <80000000>;
>> +        spi-max-frequency = <104000000>;
>> +        spi-cs-setup-ns = /bits/ 16 <7>;
> 
> Following the different changes that happened to this property after
> this post, am I right saying that this must now be changed to:
> 
> spi-cs-setup-delay-ns = <7>;
> 
> ?
> 

Yes, that should do it. I'm amending the series right now. Can you do a
little test on your side so that we make sure everything is in place?
After the update, something like that should be run on any board (maybe
wlsom1-ek?):
#!/bin/sh

dd if=/dev/urandom of=./qspi_test bs=1M count=6
mtd_debug write /dev/mtd5 0 6291456 qspi_test
mtd_debug erase /dev/mtd5 0 6291456
mtd_debug read /dev/mtd5 0 6291456 qspi_read
hexdump qspi_read
mtd_debug write /dev/mtd5 0 6291456 qspi_test
mtd_debug read /dev/mtd5 0 6291456 qspi_read
sha1sum qspi_test qspi_read

brb,
ta