All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Pringlemeir <bpringlemeir@nbsps.com>
To: b32955@freescale.com (Huang Shijie)
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] mtd: gpmi: fix the bitflips for erased page
Date: Thu, 09 Jan 2014 15:08:08 -0500	[thread overview]
Message-ID: <87ppo09avr.fsf@nbsps.com> (raw)
In-Reply-To: <1389251514-30153-1-git-send-email-b32955@freescale.com> (Huang Shijie's message of "Thu, 9 Jan 2014 15:11:54 +0800")

On  9 Jan 2014, b32955 at freescale.com wrote:

> ---
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 44 ++++++++++++++++++++++++++++++++
> 1 files changed, 44 insertions(+), 0 deletions(-)

[snip]

> +	if (flip_bits < threshold) {

Isn't it "if (flip_bits <= threshold)"?

> +		dev_dbg(this->dev, "check for the erased page:%d, chunk:%d\n",
> +				page, chunk);
> +		flip_bits = 0;
> +		memset(buf, 0, geo->payload_size);
> +
> +		/* read out the page without ECC enabled, and check it again. */
> +		chip->cmdfunc(mtd, NAND_CMD_READ0, 0, page);
> +		chip->read_buf(mtd, buf, geo->payload_size);
> +
> +		for (i = 0; i < geo->payload_size; i++)
> +			flip_bits += hweight8(~buf[i]);
> +
> +		if (flip_bits < threshold)

Perhaps the same?  At least 'strength' means the number of correctable
bit flips; or maybe you have multiple buffers?  It is just the boundary
of when an erase page is about to go bad, which might be hard to see
through testing?  I have the same issue with the Vybrid NFC and ECC, so
I maybe copying your code.

Thanks,
Bill Pringlemeir.

  reply	other threads:[~2014-01-09 20:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-03 21:27 [PATCH v7] mtd: gpmi: Deal with bitflips in erased regions Elie De Brauwer
2014-01-03 21:27 ` Elie De Brauwer
2014-01-04 12:50   ` Huang Shijie
2014-01-07  2:13   ` Huang Shijie
2014-01-09  7:11 ` [PATCH] mtd: gpmi: fix the bitflips for erased page Huang Shijie
2014-01-09 20:08   ` Bill Pringlemeir [this message]
2014-01-10  1:53     ` Huang Shijie

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=87ppo09avr.fsf@nbsps.com \
    --to=bpringlemeir@nbsps.com \
    --cc=b32955@freescale.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.