All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@logfs.org>
To: Alexey Korolev <akorolev@infradead.org>
Cc: linux-mtd@lists.infradead.org, tglx@linutronix.de,
	dwmw2@infradead.org, vasiliy.leonenko@gmail.com
Subject: Re: [RFC/PATCH 2/3] NAND multiple plane feature
Date: Sun, 1 Jun 2008 19:48:42 +0200	[thread overview]
Message-ID: <20080601174841.GH13094@logfs.org> (raw)
In-Reply-To: <alpine.LFD.1.10.0805281342150.23606@pentafluge.infradead.org>

On Wed, 28 May 2008 14:08:01 +0100, Alexey Korolev wrote:
> 
> As NAND multiple plane architecture assumes simultaneous write/erase of
> several pages/blocks at the same time, we have to modify page/eraseblock
> sizes and report modified size to upper layers. In other words physical
> erase block size/ page size != reported erase block size/ page size.
> For example if we have dual plane device we have to extend erase block
> size and page size in 2 times. 

Before actually reading the datasheets (just now) I had hoped that
manufacturers would provide us several independent read/write/erase
units per chip and allow software to deal with each plane as if it was a
seperate chip.  _That_ would have been really useful.  And for NOR
flashes, Intel has already shown how to do it.

But hoping for manufacturers to get it right rarely works - it certainly
didn't work in this case.  As it seems, we can either program two planes
in a weird lock-step process or ignore the feature.  And the lock-step
variant isn't useful for much more than doubling/quadrupling the
erasesize and writesize.  With all the disadvantages that brings. :(

Speaking about the disadvantages, if the dual plane feature is
enabled/disabled across reboots and erase size or write size changes,
we're in for a lot of fun from the filesystem size.  F.e. JFFS2 will
experience data loss when erase size isn't stable.

Jörn

-- 
All models are wrong. Some models are useful.
-- George Box

  reply	other threads:[~2008-06-01 17:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-28 13:08 [RFC/PATCH 2/3] NAND multiple plane feature Alexey Korolev
2008-06-01 17:48 ` Jörn Engel [this message]
2008-06-02 11:28   ` Jamie Lokier
2008-06-02 11:36     ` Jörn Engel
2008-06-03 16:57   ` Alexey Korolev
2008-06-03 17:20     ` Jörn Engel
2008-06-05 21:09     ` Jörn Engel
2008-06-06 14:01       ` Alexey Korolev
2008-06-06 16:22         ` Jörn Engel
2008-06-03 17:42 ` Jörn Engel
2008-06-05 16:58   ` Alexey Korolev
2008-06-05 18:58     ` Jörn Engel
2008-06-05 19:13     ` Thomas Gleixner
2008-06-06 10:08       ` Alexey Korolev
2008-06-06 12:16         ` Thomas Gleixner
2008-06-06 13:47           ` Alexey Korolev
2008-06-06 14:19             ` Thomas Gleixner
2008-06-06 14:36               ` Alexey Korolev
2008-06-05 20:03 ` Thomas Gleixner
2008-06-10 17:33   ` Alexey Korolev

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=20080601174841.GH13094@logfs.org \
    --to=joern@logfs.org \
    --cc=akorolev@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vasiliy.leonenko@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.