All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: eliedebrauwer@gmail.com, bpringlemeir@nbsps.com,
	Vikram.Narayanan@in.bosch.com, linux-mtd@lists.infradead.org,
	Pekon Gupta <pekon@ti.com>,
	dwmw2@infradead.org
Subject: Re: [PATCH V4] mtd: gpmi: fix the bitflips for erased page
Date: Thu, 13 Mar 2014 15:12:59 +0800	[thread overview]
Message-ID: <20140313071223.GA7807@shlinux2.ap.freescale.net> (raw)
In-Reply-To: <20140313054118.GR31517@norris-Latitude-E6410>

On Wed, Mar 12, 2014 at 10:41:18PM -0700, Brian Norris wrote:
> On Wed, Mar 12, 2014 at 03:26:57PM +0800, Huang Shijie wrote:
> > On Fri, Mar 07, 2014 at 07:32:38PM -0800, Brian Norris 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.
> > > 
> > > This threshold looks wrong here.
> > 
> > I shrink the threshold on purpose. The ECC strength can be 40 some times.
> 
> I see. I suppose the threshold could be smaller, but I definitely
> believe it should be correlated with the ECC strength, not just capped
> at 6 or 7.

could you suggest a better threshold? I am not confident to use the
ECC strength. 


> > > > +
> > > > +	/* Count the bitflips for the no ECC buffer */
> > > > +	for (i = 0; i < mtd->writesize / 8; i++) {
> 
> I believe I misread this loop the first time; you're not actually
> checking the entire page.
> 
> Why divide by 8?
I use the hweight64 here.

> 
> > > > +		flip_bits_noecc += hweight64(~buf[i]);
> > > > +		if (flip_bits_noecc > threshold)
> > > > +			return false;
> > > > +	}
> > > 
> > > ^^^ this loop should be broken up into sectors, so that you actually
> > > count max_bitflips per sector, not for the whole page.
> > count the max_bitflips per sector make the code more complicated.
> 
> It's only prohibitively complex because your 'raw' layout is so much
> different than your 'read with ECC' layout. If your driver conformed to
The gpmi uses the HW ECC, not software ECC. So the raw layout is a 
a little strange.



> > > > +
> > > > +	/* Tell the upper layer the bitflips we corrected. */
> > > > +	mtd->ecc_stats.corrected += flip_bits;
> > > > +	*max_bitflips = max_t(unsigned int, *max_bitflips, flip_bits);
> > > 
> > > This is wrong. You don't want to use the existing *max_bitflips value
> > > from the previous read (remember, you're re-reading the data). You
> > > should be doing a max() over each sector in the raw page, as mentioned
> > > above.
> > yes, I just tell the upper layer the max_bitflips for the ECC read, not the
> > raw read.
> 
> If you're at this point, then you have a mostly-0xff page anyway, and
> *max_bitflips should already be 0 (since your BCH can't correct such a
> page), so that's not a big deal I guess. But it still doesn't make sense
> to use the old value, if you're counting the bitflips yourself.
ok, i agree to use the new bitflips from the raw data now.

thanks
Huang Shijie

  reply	other threads:[~2014-03-13  8:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13  8:47 [PATCH V4] mtd: gpmi: fix the bitflips for erased page Huang Shijie
2014-02-21  6:08 ` Huang Shijie
2014-03-03  7:47   ` Elie De Brauwer
2014-03-07  7:56     ` Brian Norris
2014-03-07  7:58       ` Brian Norris
2014-03-07  8:23       ` Huang Shijie
2014-03-08  3:32 ` Brian Norris
2014-03-12  7:26   ` Huang Shijie
2014-03-13  5:41     ` Brian Norris
2014-03-13  7:12       ` Huang Shijie [this message]
2014-03-17 16:20         ` Brian Norris

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=20140313071223.GA7807@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 \
    --cc=pekon@ti.com \
    /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.