linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: miquel.raynal@bootlin.com, dwmw2@infradead.org,
	computersforpeace@gmail.com, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, Richard Weinberger <richard@nod.at>,
	Marek Vasut <marek.vasut@gmail.com>
Subject: Re: [RFC PATCH v2 6/6] mtd: rawnand: micron: support 8/512 on-die ECC
Date: Tue, 19 Jun 2018 08:09:59 +0200	[thread overview]
Message-ID: <20180619080959.3e0416f8@bbrezillon> (raw)
In-Reply-To: <20180619053125.16792-7-chris.packham@alliedtelesis.co.nz>

On Tue, 19 Jun 2018 17:31:25 +1200
Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:

> Micron MT29F1G08ABAFAWP-ITE:F supports an on-die ECC with 8 bits
> per 512 bytes. Add support for this combination.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> This seems deceptively easy so I've probably missed something. I have
> tested with running some of the ubifs stress tests from mtd-utils and
> things seem OK.
> 
> Changes in v2:
> - New
> 
>  drivers/mtd/nand/raw/nand_micron.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> index d1e8f57544a0..2164dd112f5c 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -240,9 +240,9 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
>  
>  	/*
>  	 * Some Micron NANDs have an on-die ECC of 4/512, some other
> -	 * 8/512. We only support the former.
> +	 * 8/512.
>  	 */
> -	if (chip->ecc_strength_ds != 4)
> +	if (chip->ecc_strength_ds != 4 && chip->ecc_strength_ds != 8)
>  		return MICRON_ON_DIE_UNSUPPORTED;

I remember that chips with 8bits/512bytes on-die ECC had an extra
command to query a more precise number of bitflips (see this
discussion [1]). It's probably worth implementing that, since those
chips are more likely to have bitflips than the 4bit/512 versions, and
you don't want to move the data around as soon as you have one bitflip. 

>  
>  	return MICRON_ON_DIE_SUPPORTED;
> @@ -274,9 +274,9 @@ static int micron_nand_init(struct nand_chip *chip)
>  			return -EINVAL;
>  		}
>  
> -		chip->ecc.bytes = 8;
> +		chip->ecc.bytes = chip->ecc_strength_ds * 2;
>  		chip->ecc.size = 512;
> -		chip->ecc.strength = 4;
> +		chip->ecc.strength = chip->ecc_strength_ds;
>  		chip->ecc.algo = NAND_ECC_BCH;
>  		chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
>  		chip->ecc.write_page = micron_nand_write_page_on_die_ecc;

[1]http://lists.infradead.org/pipermail/linux-mtd/2017-March/072974.html

      reply	other threads:[~2018-06-19  6:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19  5:31 [RFC PATCH v2 0/6] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F Chris Packham
2018-06-19  5:31 ` [RFC PATCH v2 1/6] mtd: rawnand: marvell: Handle on-die ECC Chris Packham
2018-06-19  5:58   ` Boris Brezillon
2018-06-19  5:31 ` [RFC PATCH v2 2/6] mtd: rawnand: add manufacturer fixup for ONFI parameter page Chris Packham
2018-06-19  6:01   ` Boris Brezillon
2018-06-19  5:31 ` [RFC PATCH v2 3/6] mtd: rawnand: micron: add fixup for ONFI revision Chris Packham
2018-06-19  6:02   ` Boris Brezillon
2018-06-19  5:31 ` [RFC PATCH v2 4/6] mtd: rawnand: marvell: Support page size of 2048 with 8-bit ECC Chris Packham
2018-06-19  5:31 ` [RFC PATCH v2 5/6] mtd: rawnand: micron: add ONFI_FEATURE_ON_DIE_ECC to supported features Chris Packham
2018-06-19  5:40   ` Boris Brezillon
2018-06-19  6:52     ` Miquel Raynal
2018-06-19 21:22       ` Chris Packham
2018-06-20  7:43         ` Miquel Raynal
2018-06-19  9:00     ` Miquel Raynal
2018-06-20  9:40   ` Boris Brezillon
2018-06-19  5:31 ` [RFC PATCH v2 6/6] mtd: rawnand: micron: support 8/512 on-die ECC Chris Packham
2018-06-19  6:09   ` Boris Brezillon [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=20180619080959.3e0416f8@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    /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;
as well as URLs for NNTP newsgroup(s).