public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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