From: Alexander Sverdlin <alexander.sverdlin@nokia.com>
To: Tudor.Ambarus@microchip.com, luisalberto@google.com
Cc: vigneshr@ti.com, bbrezillon@kernel.org, richard@nod.at,
jethro@fortanix.com, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
mika.westerberg@linux.intel.com
Subject: Re: [PATCH] mtd: revert "spi-nor: intel: provide a range for poll_timout"
Date: Thu, 23 Jul 2020 11:05:41 +0200 [thread overview]
Message-ID: <ca4d6a2f-b3c8-2b52-431e-81f3cb956db7@nokia.com> (raw)
In-Reply-To: <df774dcb-edd1-ae7a-0e26-2e7c324406ff@microchip.com>
Hello Tudor,
On 22/07/2020 19:03, Tudor.Ambarus@microchip.com wrote:
> On 7/22/20 7:37 PM, Alexander Sverdlin wrote:
[...]
>> I've performed my testing as well and got the following results:
>>
>> Vanilla Linux 4.9 (i.e. before the introduction of the offending
>> patch):
>>
>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k
>> 1280+0 records in
>> 1280+0 records out
>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.91981 s, 1.3 MB/s
>>
>> Vanilla 4.19 (i.e. with offending patch):
>>
>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k
>> 1280+0 records in
>> 1280+0 records out
>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 6.70891 s, 781 kB/s
>>
>> 4.19 + revert:
>>
>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k
>> 1280+0 records in
>> 1280+0 records out
>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.90503 s, 1.3 MB/s
>>
>> Therefore it looks good from my PoV:
>>
>> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
[...]
> would you put 10 us here
>>> INTEL_SPI_TIMEOUT * 1000);
>>> }
>>>
>>> @@ -301,7 +301,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi *ispi)
>>> u32 val;
>>>
>>> return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
>>> - !(val & SSFSTS_CTL_SCIP), 40,
>>> + !(val & SSFSTS_CTL_SCIP), 0,
>
> also here, and re-do a test? I'm curios if the performance will be
> as it was before.
with 10us it looks like this:
dd if=/dev/flash/by-name/... of=/dev/null bs=4k
1280+0 records in
1280+0 records out
5242880 bytes (5.2 MB, 5.0 MiB) copied, 4.33816 s, 1.2 MB/s
Which means, there is a performance regression and it would depend on
the test case, how bad it will be...
--
Best regards,
Alexander Sverdlin.
next prev parent reply other threads:[~2020-07-23 9:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-10 22:46 Luis Alberto Herrera
2020-06-11 10:39 ` Mika Westerberg
2020-06-26 10:57 ` Tudor.Ambarus
2020-07-22 16:37 ` Alexander Sverdlin
2020-07-22 17:03 ` Tudor.Ambarus
2020-07-23 9:05 ` Alexander Sverdlin [this message]
2020-07-28 8:28 ` Tudor.Ambarus
2020-07-28 9:55 ` Tudor Ambarus
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=ca4d6a2f-b3c8-2b52-431e-81f3cb956db7@nokia.com \
--to=alexander.sverdlin@nokia.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=bbrezillon@kernel.org \
--cc=jethro@fortanix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=luisalberto@google.com \
--cc=mika.westerberg@linux.intel.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/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
Powered by JetHome