All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: "Richard Weinberger" <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	"David Woodhouse" <dwmw2@infradead.org>,
	linux-kernel@vger.kernel.org,
	"Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>
Subject: Re: [PATCH 0/4] mtd: add support for pairing scheme description
Date: Sat, 11 Jun 2016 08:45:18 +0200	[thread overview]
Message-ID: <20160611084518.61d9b712@bbrezillon> (raw)
In-Reply-To: <20160611021625.GA144502@google.com>

On Fri, 10 Jun 2016 19:16:25 -0700
Brian Norris <computersforpeace@gmail.com> wrote:

> Hi Boris,
> 
> I've mostly just reviewed the cover and first patch for now, since that
> sets up the rest. A few questions and comments. I hope to review some
> more and have more to say later this weekend.
> 
> On Mon, Apr 25, 2016 at 12:01:17PM +0200, Boris Brezillon wrote:
> > Hi,
> > 
> > This series is the first step towards reliable MLC/TLC NAND support.
> > Those patches allows the NAND layer to expose page pairing information
> > to MTD users.  
> 
> Have you surveyed many types of NAND to get a representative sampling of
> what kind of pairing schemes are out there? Do you think you've covered
> the possibilities well enough in your API? I have a few comments on the
> patches to this effect. I honestly don't know the answer to these
> questions, because AFAIR, this is rarely well documented in datasheets.

I only tested on 3 different NANDs from Micron, Toshiba and Hynix, but
I had a look at several datasheets. Unlike read-retry this part is
usually documented in public datasheets, and on a panel of approximately
20 NANDs (mainly from Toshiba, Samsung, Hynix and Micron), all of them
where using the 'distance 3' or 'distance 6' pairing scheme.
The only exception I've seen so far is the one pointed by Bean here [1],
and it can be described using the mtd_pairing_scheme approach.

> 
> > The plan is to teach UBI about those constraints and let UBI code take
> > the appropriate precautions when dealing with those multi-level cells
> > NANDs. The way we'll handle this "paired pages" constraint will be
> > described soon in a series adapting the UBI layer, so stay tune ;).
> > 
> > Note that this implementation only allows page pairing scheme description
> > when the NAND has a full-id entry in the nand_ids table.
> > This should be addressed in some way for ONFI and JEDEC NANDs, though
> > I'm not sure how to handle this yet.  
> 
> Do ONFI or JEDEC parameter pages even provide this kind of info? The
> ONFI spec doesn't mention paired pages.

Nope that's the problem. The only way you can deduce that is to extract
it from other information, but I think my series reworking the NAND
initialization will help us [2].


[1]http://thread.gmane.org/gmane.linux.drivers.mtd/67084
[2]https://lkml.org/lkml/2016/5/27/264

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

  reply	other threads:[~2016-06-11  6:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 10:01 [PATCH 0/4] mtd: add support for pairing scheme description Boris Brezillon
2016-04-25 10:01 ` [PATCH 1/4] mtd: introduce the mtd_pairing_scheme concept Boris Brezillon
2016-06-11  2:17   ` Brian Norris
2016-06-11  6:54     ` Boris Brezillon
2016-06-13  5:55       ` Brian Norris
2016-06-13  6:22         ` Brian Norris
2016-06-13  6:37           ` Boris Brezillon
2016-04-25 10:01 ` [PATCH 2/4] mtd: nand: implement two pairing scheme Boris Brezillon
2016-04-25 10:01 ` [PATCH 3/4] mtd: nand: add a pairing field to nand_flash_dev Boris Brezillon
2016-04-25 10:01 ` [PATCH 4/4] mtd: nand: H27UCG8T2ATR: point to the correct pairing scheme implementation Boris Brezillon
2016-04-28  8:04 ` [PATCH 0/4] mtd: add support for pairing scheme description Richard Weinberger
2016-06-11  2:16 ` Brian Norris
2016-06-11  6:45   ` Boris Brezillon [this message]
2016-06-13  5:54     ` Brian Norris
2016-06-13  6:33       ` Boris Brezillon

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=20160611084518.61d9b712@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=beanhuo@micron.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --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 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.