All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Andrea Marson <andrea.marson@dave.eu>
Cc: Andrea Scian <rnd4@dave-tech.it>,
	"Jeff Lauruhn \(jlauruhn\)" <jlauruhn@micron.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>,
	Richard Weinberger <richard@nod.at>
Subject: Re: RFC: detect and manage power cut on MLC NAND
Date: Thu, 19 Mar 2015 10:12:46 +0100	[thread overview]
Message-ID: <20150319101246.26806e95@bbrezillon> (raw)
In-Reply-To: <550A8D19.90404@dave.eu>

On Thu, 19 Mar 2015 09:47:21 +0100
Andrea Marson <andrea.marson@dave.eu> wrote:

> > Disturb is a block level affect, as long as partition A and B are in different blocks there will be no disturb between them.   Disturbs, does not damage cells; ERASE returns cells to undisturbed levels.
> I think there are two options here: MTD partitioning and UBI 
> partitioning. AFAIK one should prefer UBI partitioning to preserve 
> device-wide wear leveling. Boris, am I right?

Both of them act at block level, meaning that your the partition size
must be a multiple of the block size (logical block size in case of UBI
volume and physical block size in case of MTD partition).
IOW, you shouldn't bother whether you're using UBI on top of MTD or
directly using MTD partitions, both are immune to cross partition/volume
read/write disturbance.


> 
> > Officially I would say don't use SLC emulation, but technically I know what your doing.   The reason I say no is because we have very precise recipes designed to create very tight distibutions, and although the first pass distributions might look like an SLC, they are really designed with the expectation of the upper page being programmed.  Not a true SLC.
> > With MLC lithography of 25 nm and less  the difference between each level (L0, L1, L2 and L3) is just a few 10's of electrons.  The distribution have to be very tight, in order to meet retention requirements.
> This is quite interesting, however I'm afraid I have not fully 
> understood it.

Me neither :-/.

> Let me try to rephrase it. Please correct me if I'm wrong.
> 
> 1) Technically speaking, it is possible to use an MLC memory in SLC 
> mode, even if this is not recommended because MLC is not designed for 
> this usage.

That's what I understood, but I'm not sure to understand the
constraints brought by SLC mode (only programming one of the paired
pages).
Jeff, Are you trying to explain what's described here [1] in slide 8
(BTW I'm not sure to understand this diagram).
If that's the case, could you explain us, how the NAND chip knows which
threshold should be used (does it somehow store the information of
which page has already been programmed)

[1]http://www.bswd.com/FMS09/FMS09-T2A-Grunzke.pdf

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2015-03-19  9:13 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 [this message]
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)
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=20150319101246.26806e95@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=andrea.marson@dave.eu \
    --cc=dedekind1@gmail.com \
    --cc=jlauruhn@micron.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=rnd4@dave-tech.it \
    /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.