[ANNOUNCE] MLC support for UBI/UBIFS

Boris Brezillon boris.brezillon at free-electrons.com
Wed May 4 11:59:06 PDT 2016


On Wed, 4 May 2016 11:17:35 +0200
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> On Wed, 4 May 2016 08:55:12 +0000
> Bean Huo 霍斌斌 (beanhuo) <beanhuo at 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



More information about the linux-mtd mailing list