From: Huang Shijie <b32955@freescale.com>
To: Bill Pringlemeir <bpringlemeir@nbsps.com>
Cc: Vikram.Narayanan@in.bosch.com, eliedebrauwer@gmail.com,
computersforpeace@gmail.com, dwmw2@infradead.org,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH V2 fix] mtd: gpmi: fix the bitflips for erased page
Date: Mon, 13 Jan 2014 10:10:54 +0800 [thread overview]
Message-ID: <20140113021052.GA17069@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <87eh4ftyja.fsf@nbsps.com>
On Fri, Jan 10, 2014 at 02:41:29PM -0500, Bill Pringlemeir wrote:
> On 10 Jan 2014, b32955@freescale.com wrote:
>
> > This patch does a check for the uncorrectable failure in the following
> > steps:
>
> > [0] set the threshold. The threshold is set based on the truth: "A
> > single 0 bit will lead to gf_len(13 or 14) bits 0 after the BCH do the
> > ECC."
>
> > For the sake of safe, we will set the threshold with half the gf_len,
> > and do not make it bigger the ECC strength.
>
> > [1] count the bitflips of the current ECC chunk, assume it is N.
>
> > [2] if the (N <= threshold) is true, we continue to read out the page
> > with ECC disabled. and we count the bitflips again, assume it is N2.
>
> > [3] if the (N2 <= threshold) is true again, we can regard this is a
> > erased page. This is because a real erased page is full of 0xFF(maybe
> > also has several bitflips), while a page contains the 0xFF data will
> > definitely has many bitflips in the ECC parity area.
>
> > [4] if the [3] fails, we can regard this is a page filled with the
> > '0xFF' data.
>
> Sorry, I am a slow thinker. Why do we bother with steps 0-2 at all?
> Why not just read the page without ECC on an un-correctable error.
Nearly all the nand chips (<19nm) have the read-retry feature.
The steps 0-2 is for the read-retry shortcut.
If we remove steps 0-2, the read-retry will have to read out the buffer
with ECC disabled for each times the uncorrectable error occur, it will
slower the READ-Retry. :)
Most of the read-retry may need 8 times ECC reads or even more. So we'd
better keep the steps 0-2.
> Another driver (which I was patterning off of) is the fsmc_nand.c and
> it's count_written_bits() routine.
I think it is okay to add the similar shortcut code for steps 0-2.
I will add it in the next version.
thanks
Huang Shijie
prev parent reply other threads:[~2014-01-13 2:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 8:37 [PATCH V2] mtd: gpmi: fix the bitflips for erased page Huang Shijie
2014-01-10 8:41 ` [PATCH V2 fix] " Huang Shijie
2014-01-10 19:41 ` Bill Pringlemeir
2014-01-10 20:46 ` HW-ECC and erase detect [was: PATCH V2 fix mtd: gpmi: fix the bitflips for erased page] Bill Pringlemeir
2014-01-13 2:15 ` Huang Shijie
2014-01-13 2:10 ` Huang Shijie [this message]
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=20140113021052.GA17069@shlinux2.ap.freescale.net \
--to=b32955@freescale.com \
--cc=Vikram.Narayanan@in.bosch.com \
--cc=bpringlemeir@nbsps.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=eliedebrauwer@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/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.