public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Vitaly Wool <vwool@ru.mvista.com>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: more flexible HW ECC support for nand_base
Date: Fri, 30 Sep 2005 15:57:09 +0400	[thread overview]
Message-ID: <433D2815.6040603@ru.mvista.com> (raw)

Hi  Thomas,

as you might recall, during the PNX4008 LSP development we came across 
the MTD problem which turned to be a shipstopper for hardware ECC 
support on SanDisk MLC controller.  The patch (quite inmature) suggested 
and a kind of struggle around it are in September linux-mtd e-mail 
archive ;-)
The problem basically is that the MTD NAND core assumes that layout is 
like "(data bytes) (possible ecc data) (oob data)", and more often just 
"(data bytes) (oob data)". To perform ECC data reading, the NAND chip 
driver needs to set the special option like NAND_HWECC_SYNDROME.
On the other hand, the page layout may vary from chip to chip. For 
SanDisk MLC it looks like 
"(data)(ecc)(oob)(data)(ecc)(oob)(data)(ecc)(oob)(data)(ecc)(oob)" what 
can't be handled properly by nand_base since it doesn't even try to read 
OOB data in loop (i. e. eccsteps times).

After some local discussions, we suggest the following modification to 
the MTD NAND core to allow driver to specify its own layout of nand 
page. Namely, the solution proposed is to provide the `page_layout' 
field in nand_chip structure, that will point to array of structures like

struct page_layout_item {
    int length;
    enum {
        SPARE, DATA, OOB, ECC,
    } type;
}

Any standard types like NAND_HW512_6 will be replaced then by standard 
layouts like
    nand_layout_512_6 = {
        { 512, DATA },
        { 6, ECC },
    };
The rest of page, if any, might be considered as OOB data or explicitly 
defined, like
        { 10, OOB }

Another part of the problem is nand_read_oob()/nand_write_oob() 
functions that also make assumptions on NAND flash page layout. It's 
suggested that they go to nand_chip structure, i. e. it will become a 
specific chip driver's responsibility to provide those; and if driver 
does not provide one, the current implementation can be used. If 
nand_chip provides its own layout, it must read/write oob data according 
to the layout.

These steps should provide backward compatibility and the ability for 
particular driver owners to update their drivers accordingly with as 
less pain as possible.

Any comments are welcome,

Best regards,
  Vitaly

             reply	other threads:[~2005-09-30 11:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-30 11:57 Vitaly Wool [this message]
2005-10-15 20:46 ` more flexible HW ECC support for nand_base Charles Manning
2005-10-18 12:00   ` Vitaly Wool

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=433D2815.6040603@ru.mvista.com \
    --to=vwool@ru.mvista.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /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