All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <shijie8@gmail.com>
To: Elie De Brauwer <eliedebrauwer@gmail.com>
Cc: b32955@freescale.com, computersforpeace@gmail.com,
	dwmw2@infradead.org, linux-mtd@lists.infradead.org,
	dedekind1@gmail.com
Subject: Re: [PATCH v5] mtd: gpmi: Deal with bitflips in erased regions regions
Date: Wed, 18 Dec 2013 13:21:09 +0800	[thread overview]
Message-ID: <20131218052108.GA1696@gmail.com> (raw)
In-Reply-To: <1387287942-20694-1-git-send-email-eliedebrauwer@gmail.com>

On Tue, Dec 17, 2013 at 02:45:42PM +0100, Elie De Brauwer wrote:
>  
> +	/* Set the tolerance for bitflips when reading erased blocks. */
> +	erase_threshold = gf_len / 2;
> +	if (erase_threshold > ecc_strength)
> +		erase_threshold = ecc_strength;
> +
I was about to give you my ACK, but i find you used a wrong ecc strength
here.  The "ecc_strength" is just half of the real ECC strength used by
the BCH. Please read this line in the function:
268	ecc_strength  = bch_geo->ecc_strength >> 1;

Could you please send a new version patch ?


> +	writel(erase_threshold & BM_BCH_MODE_ERASE_THRESHOLD_MASK,
> +		r->bch_regs + HW_BCH_MODE);
> +
>  	/* Set *all* chip selects to use layout 0. */
>  	writel(0, r->bch_regs + HW_BCH_LAYOUTSELECT);
>  
> @@ -1094,6 +1103,15 @@ int gpmi_is_ready(struct gpmi_nand_data *this, unsigned chip)
>  	return reg & mask;
>  }
>  
> +/*
> + * Count the number of 0 bits in a supposed to be
> + * erased region and correct them. Return the number
> + * of bitflips or zero when the region was correct.
> + */
> +static unsigned int erased_sector_bitflips(unsigned char *data,
> +					unsigned int chunk,
> +					struct bch_geometry *geo)
> +{
> +	unsigned int flip_bits = 0;
> +	int i;
> +	int base = geo->ecc_chunk_size * chunk;
> +
> +	/* Count bitflips */
> +	for (i = 0; i < geo->ecc_chunk_size; i++)
> +		flip_bits += hweight8(~data[base + i]);
> +
> +	/* Correct bitflips by 0xFF'ing this chunk. */
> +	if (flip_bits)
> +		memset(&data[base], 0xFF, geo->ecc_chunk_size);
> +
> +	return flip_bits;
> +}

Since a new version patch is inevitable, i want to give more comment
about this function.


Does the following code run faster then above?
static unsigned int erased_sector_bitflips(unsigned char *data,
					unsigned int chunk,
					struct bch_geometry *geo)
{
	unsigned int flip_bits = 0;
	int i;
	int base = geo->ecc_chunk_size * chunk;
	int tmp;

	for (i = 0; i < geo->ecc_chunk_size; i++) {
		tmp = hweight8(~data[base + i]);

		if (tmp) {
			data[base + i] = 0xff;
			flip_bits += tmp;
		}
	}

	return flip_bits;
}

I am not sure this code is faster then your code, i do not have time to
do a test to compare the two functions.

If you think your function is better, just ignore my code, it is okay to
me.

I really very appreciate at your work!

thanks
Huang Shijie

  reply	other threads:[~2013-12-18  5:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17 13:45 [PATCH v5] mtd: gpmi: Deal with bitflips in erased regions regions Elie De Brauwer
2013-12-18  5:21 ` Huang Shijie [this message]
2013-12-18  7:50   ` Elie De Brauwer

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=20131218052108.GA1696@gmail.com \
    --to=shijie8@gmail.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@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.