linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>
Cc: Richard Weinberger <richard@nod.at>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Alexander Kaplan <alex@nextthing.co>,
	David Gstir <david@sigma-star.at>,
	David Oberhollenzer <goliath@sigma-star.at>,
	Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [ANNOUNCE] MLC support for UBI/UBIFS
Date: Wed, 4 May 2016 11:17:35 +0200	[thread overview]
Message-ID: <20160504111735.33b96d7e@bbrezillon> (raw)
In-Reply-To: <A765B125120D1346A63912DDE6D8B6310BF70101@NTXXIAMBX02.xacn.micron.com>

On Wed, 4 May 2016 08:55:12 +0000
Bean Huo 霍斌斌 (beanhuo) <beanhuo@micron.com> wrote:

> Hi, Richard
> Yes , different with "dis6 and dis3", but I think this is not a perfect 
> Solution on paired-page distance detect. Because different vendor and different series NAND with different such paired-page distance function. as a result, this table will be bigger and bigger. I now want to do if we can probe this information from DTS.

Sorry but I'm clearly opposed to that: the NAND infrastructure provides
a way to uniquely identify the part number, let's not add extra
information in the DT if it's not needed.
Just giving a simple use case where putting NAND chip details in the DT
is a bad idea: some board manufacturers choose 2 or 3 equivalent NANDs
coming from different vendors (and those NANDs may have different
pairing scheme). With your solution this means having one DT per NAND
chip, which is not easy to deal with.

For the "the table will keep growing and become unmaintainable"
argument, I agree. My plan is to provide a per-vendor ->init() hook
so that each vendor can implement a simpler solution to detect/assign
the pairing scheme (I'm pretty sure this is correlated to the NAND
technology...), or other vendor specific stuff (read-retry, HW SLC
mode, ...).

Regarding your initial statement, are you sure your NAND chip does not
use one of the already defined scheme. I had a look at several NAND
datasheets (including Micron ones), and all of them were using either
distance 3 or distance 6.
Can you share more information about those different pairing scheme?

Thanks,

Boris


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

  reply	other threads:[~2016-05-04  9:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 14:28 [ANNOUNCE] MLC support for UBI/UBIFS Richard Weinberger
2016-05-04  7:40 ` Bean Huo 霍斌斌 (beanhuo)
2016-05-04  8:27   ` Richard Weinberger
2016-05-04  8:55     ` Bean Huo 霍斌斌 (beanhuo)
2016-05-04  9:17       ` Boris Brezillon [this message]
2016-05-04 18:59         ` Boris Brezillon
2016-05-04  9:18       ` Richard Weinberger

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=20160504111735.33b96d7e@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=alex@nextthing.co \
    --cc=beanhuo@micron.com \
    --cc=david@sigma-star.at \
    --cc=dedekind1@gmail.com \
    --cc=goliath@sigma-star.at \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).