All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jeff Lauruhn (jlauruhn)" <jlauruhn@micron.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: mtd_mailinglist <linux-mtd@lists.infradead.org>
Subject: RE: RFC: detect and manage power cut on MLC NAND
Date: Mon, 16 Mar 2015 17:27:39 +0000	[thread overview]
Message-ID: <0D23F1ECC880A74392D56535BCADD7354973E0EC@NTXBOIMBX03.micron.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1503160955000.7125@lnxricardw1.se.axis.com>

Ricard;
I wish I could add some images, they would really help.  But, what you call paired pages we call lower/upper pagers.  Any yes, it's all about the distribution.  I need to look in to other vendors but under program operations for Micron we have a requirement "Within a block, pages must be programmed sequentially from the least significant page address to the most significant page address (i.e. 0, 1, 2, 3, .). Programming pages out of order within a block is prohibited." This ensures that the lower page is programmed, before the upper page and that they are programmed together.  This sequence ensures the best reliability.  When we program the lower page it gets programmed into L0 or L1 state, when we program the upper page we either move L0 or L1 to its final location and we end up with L0, L1, L2, or L3.  Programming takes longer because there are 4 levels on the same gate so tighter distribution is required.  Power loss isn't as big an issue as it was in the past, most vendors are aware and have power loss considerations, but there are still vendors who take the risk.  In the case of a power loss during a upper page program it's always a good idea to check the condition of the lower page. 

Jeff Lauruhn
NAND Application Engineer
Embedded Business Unit


-----Original Message-----
From: Ricard Wanderlof [mailto:ricard.wanderlof@axis.com] 
Sent: Monday, March 16, 2015 2:02 AM
To: Jeff Lauruhn (jlauruhn)
Cc: mtd_mailinglist
Subject: Re: RFC: detect and manage power cut on MLC NAND


Hi Jeff,

I have a question regarding MLC:s, probably not so much something we can do anything about, but I'm curious just the same:

If I understand correctly, page pairing in MLC's means that of the two bits in a cell, one is allocated to one page and another one to a completely different page. This means (among other things) that rewriting one page may impact the other, paired, page.


My question is: why is it done this way? Is it to distribute bit flips more evenly?

An initial trivial allocation would otherwise be to put the paired bits in the same byte, for two reasons a) to avoid page-pairing issues, and b) because it simply would be easier to write both bits in a cell at the same time rather than at different times.

Granted, without page pairing, any sort of failure or disturb in one bit cell would would require twice the amount of ECC as both bits would likely be corrupted, on the other hand, we'd avoid having data in one part of the flash be corrupted by operations in another part of the flash.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

  reply	other threads:[~2015-03-16 17:28 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-10 11:57 RFC: detect and manage power cut on MLC NAND Andrea Scian
2015-03-10 12:51 ` Richard Weinberger
2015-03-11  7:20   ` Artem Bityutskiy
2015-03-11  8:57     ` Richard Weinberger
2015-03-11  9:05       ` Artem Bityutskiy
2015-03-11  9:09         ` Richard Weinberger
2015-03-11 17:01           ` Andrea Scian
2015-03-11 17:23             ` Jeff Lauruhn (jlauruhn)
2015-03-11 17:29               ` Richard Weinberger
2015-03-11 21:16                 ` Jeff Lauruhn (jlauruhn)
2015-03-12 10:28                   ` Richard Weinberger
2015-03-12 22:57                     ` Jeff Lauruhn (jlauruhn)
2015-03-13 20:31                       ` Boris Brezillon
2015-03-13 23:51                         ` Jeff Lauruhn (jlauruhn)
2015-03-14  9:46                           ` Andrea Marson - DAVE Embedded Systems
2015-03-16 16:02                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  8:00                               ` Andrea Scian
2015-03-14 10:32                           ` Boris Brezillon
2015-03-16 21:11                             ` Jeff Lauruhn (jlauruhn)
2015-03-17  9:30                               ` Andrea Scian
2015-03-17 10:02                                 ` Boris Brezillon
2015-03-17 16:42                                   ` Jeff Lauruhn (jlauruhn)
2015-03-18  8:45                                     ` RFC: detect and manage power cut on MLC NAND (linux-mtd Digest, Vol 144, Issue 70) Andrea Marson
2015-03-18  9:07                                       ` Boris Brezillon
2015-03-18  9:56                                         ` Andrea Marson
2015-03-18 10:03                                           ` Boris Brezillon
2015-03-18 12:07                                         ` Richard Weinberger
2015-03-18 17:11                                           ` Jeff Lauruhn (jlauruhn)
2015-03-18 16:12                                       ` Jeff Lauruhn (jlauruhn)
2015-03-19  8:47                                         ` RFC: detect and manage power cut on MLC NAND Andrea Marson
2015-03-19  9:12                                           ` Boris Brezillon
2015-03-19 17:45                                             ` Jeff Lauruhn (jlauruhn)
2015-03-20  0:25                                             ` Iwo Mergler
2015-03-20  3:38                                               ` nick
2015-03-20  5:40                                                 ` Iwo Mergler
2015-03-20  8:26                                               ` Boris Brezillon
2015-03-20 17:15                                                 ` Nick Krause
2015-03-22 23:45                                                 ` Iwo Mergler
2015-03-23  2:18                                                 ` Iwo Mergler
2015-03-23  7:06                                                   ` Artem Bityutskiy
2015-03-23 19:05                                                     ` Boris Brezillon
2015-03-24  7:05                                                       ` Artem Bityutskiy
2015-03-19 18:00                                           ` Jeff Lauruhn (jlauruhn)
2015-03-20  8:07                                             ` Andrea Marson
2015-03-17 17:04                                 ` Jeff Lauruhn (jlauruhn)
2015-03-16  9:01                         ` Ricard Wanderlof
2015-03-16 17:27                           ` Jeff Lauruhn (jlauruhn) [this message]
2015-03-14 10:03                       ` Richard Weinberger
2015-03-12  9:32               ` Ricard Wanderlof
2015-03-23  4:08           ` Iwo Mergler
2015-03-23 21:15             ` Jeff Lauruhn (jlauruhn)
2015-03-24  1:17               ` Iwo Mergler
2015-03-24 16:50                 ` Jeff Lauruhn (jlauruhn)
2015-03-25  3:38                   ` Iwo Mergler
2015-03-25  8:33                     ` Ricard Wanderlof
2015-03-26  1:57                       ` Jeff Lauruhn (jlauruhn)
2015-03-26  8:55                         ` Ricard Wanderlof
2015-03-11  7:21 ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2015-03-12 10:31 Andrea Marson - DAVE Embedded Systems
     [not found] <mailman.37176.1426610573.22890.linux-mtd@lists.infradead.org>

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=0D23F1ECC880A74392D56535BCADD7354973E0EC@NTXBOIMBX03.micron.com \
    --to=jlauruhn@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.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.