From: Tudor Ambarus <tudor.ambarus@microchip.com>
To: Marek Vasut <marek.vasut@gmail.com>,
Cyrille Pitchen <cyrille.pitchen@microchip.com>,
<dwmw2@infradead.org>, <computersforpeace@gmail.com>,
<boris.brezillon@bootlin.com>, <richard@nod.at>
Cc: <linux-mtd@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>
Subject: Re: support for non-uniform SPI NOR flash memories
Date: Wed, 9 May 2018 19:40:03 +0300 [thread overview]
Message-ID: <b7cbad40-8340-0a8f-e539-932b777757d8@microchip.com> (raw)
In-Reply-To: <e9218dcf-dce6-a009-70ec-33d0cac5bc4d@gmail.com>
On 05/07/2018 08:14 PM, Marek Vasut wrote:
> But indeed there are -- to my knowledge -- no flashes with interleaved
> erase blocks. And yes, there could be improvement in erasing exactly the
> required chunk of flash with a fitting opcode:)
Thanks Marek.
Other improvement would be to minimize the amount of erase() calls by
using the best sequence of erase type commands depending on alignment.
But this will increase the number of queries.
I've read again the Sector Map section of the JEDECB standard and it
looks like "overlaid" regions are possible. Here's an example that I
found there:
Bottom: 8x 4KB sectors at bottom (only 4KB erase supported),
1x overlaid 64KB sector at bottom (only 64KB erase supported),
511 uniform 64KB sectors (only 64KB erase supported)
That's interesting, when one wants to erase the overlaid 64KB sector, I
guess that the 8x 4KB sectors will be erased too.
I'm still studying this, I'll try to come with a proposal in the next
few days.
Cheers,
ta
next prev parent reply other threads:[~2018-05-09 16:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-07 17:11 support for non-uniform SPI NOR flash memories Tudor Ambarus
2018-05-07 17:14 ` Marek Vasut
2018-05-09 16:40 ` Tudor Ambarus [this message]
2018-05-10 10:19 ` Marek Vasut
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=b7cbad40-8340-0a8f-e539-932b777757d8@microchip.com \
--to=tudor.ambarus@microchip.com \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@microchip.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=nicolas.ferre@microchip.com \
--cc=richard@nod.at \
/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