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 20:59:06 +0200 [thread overview]
Message-ID: <20160504205906.15d75592@bbrezillon> (raw)
In-Reply-To: <20160504111735.33b96d7e@bbrezillon>
On Wed, 4 May 2016 11:17:35 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> 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?
Okay, I had a closer look at your "driver:mtd:ubi:add new bakvol module
in ubi layer" patch and some Micron datasheet, and it seems your L7X
NANDs are using the "standard" distance 6 scheme, but L8X are actually
using a different scheme.
This being said, I don't see any problem implementing this new scheme
(the question is, is it really used by other vendors or not).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-05-04 18:59 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
2016-05-04 18:59 ` Boris Brezillon [this message]
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=20160504205906.15d75592@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).