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: [PATCH v3 4/4] mtd: rawnand: micron: support 8/512 on-die ECC
Date: Wed, 20 Jun 2018 10:02:32 +0200 [thread overview]
Message-ID: <20180620100232.0ad18adc@bbrezillon> (raw)
In-Reply-To: <20180620050544.31549-5-chris.packham@alliedtelesis.co.nz>
On Wed, 20 Jun 2018 17:05:44 +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>
> ---
> Changes in v2:
> - New
> Changes in v3:
> - Handle reporting of corrected errors that don't require a rewrite, expand
> comment for the ECC status bits.
>
> drivers/mtd/nand/raw/nand_micron.c | 34 ++++++++++++++++++++++++------
> 1 file changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> index 5cec79372181..0c2bde4411d7 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -18,10 +18,24 @@
> #include <linux/mtd/rawnand.h>
>
> /*
> - * Special Micron status bit that indicates when the block has been
> - * corrected by on-die ECC and should be rewritten
> + * Special Micron status bit 3 indicates that the block has been
> + * corrected by on-die ECC and should be rewritten.
> + *
> + * On chips with 8-bit ECC and additional bit can be used to distinguish
> + * cases where a errors were corrected without needing a rewrite
> + *
> + * Bit 4 Bit 3 Bit 0 Description
> + * ----- ----- ----- -----------
> + * 0 0 0 No Errors
> + * 0 0 1 Multiple uncorrected errors
> + * 0 1 0 4 - 6 errors corrected, recommend rewrite
> + * 0 0 1 Reserved
> + * 1 0 0 1 - 3 errors corrected
> + * 1 0 1 Reserved
> + * 1 1 0 7 - 8 errors corrected, recommend rewrite
> */
> #define NAND_STATUS_WRITE_RECOMMENDED BIT(3)
> +#define NAND_STATUS_ERRORS_CORRECTED BIT(4)
>
> struct nand_onfi_vendor_micron {
> u8 two_plane_read;
> @@ -141,7 +155,7 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip,
> mtd->ecc_stats.failed++;
>
> /*
> - * The internal ECC doesn't tell us the number of bitflips
> + * The internal 4-bit ECC doesn't tell us the number of bitflips
> * that have been corrected, but tells us if it recommends to
> * rewrite the block. If it's the case, then we pretend we had
> * a number of bitflips equal to the ECC strength, which will
> @@ -149,6 +163,12 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip,
> */
> else if (status & NAND_STATUS_WRITE_RECOMMENDED)
> max_bitflips = chip->ecc.strength;
> + /*
> + * Chips with 8-bit internal ECC do tell us if errors 1 to 3 bit
> + * errors have been corrected without recommending a rewrite.
> + */
> + else if (status & NAND_STATUS_ERRORS_CORRECTED)
> + max_bitflips = 3;
Why not masking bit 3, 4 and 0 and having a switch-case block?
Also, you should update ecc_stats.corrected (see the patch I just sent
[1]).
>
> ret = nand_read_data_op(chip, buf, mtd->writesize, false);
> if (!ret && oob_required)
> @@ -240,9 +260,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;
Given that our on-die-support detection procedure is not reliable, I'd
recommend changing the way we do it and instead base this detection
logic on the model name (in the ONFI param page) or the READ_ID bytes.
>
> return MICRON_ON_DIE_SUPPORTED;
> @@ -274,9 +294,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://patchwork.ozlabs.org/patch/932006/
next prev parent reply other threads:[~2018-06-20 8:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 5:05 [PATCH v3 0/4] mtd: rawnand: support MT29F1G08ABAFAWP-ITE:F Chris Packham
2018-06-20 5:05 ` [PATCH v3 1/4] mtd: rawnand: marvell: Handle on-die ECC Chris Packham
2018-06-20 7:46 ` Boris Brezillon
2018-06-20 21:10 ` Chris Packham
2018-06-20 5:05 ` [PATCH v3 2/4] mtd: rawnand: add manufacturer fixup for ONFI parameter page Chris Packham
2018-06-20 7:49 ` Boris Brezillon
2018-06-20 5:05 ` [PATCH v3 3/4] mtd: rawnand: micron: add fixup for ONFI revision Chris Packham
2018-06-20 7:54 ` Boris Brezillon
2018-06-20 21:12 ` Chris Packham
2018-06-21 7:14 ` Boris Brezillon
2018-06-20 5:05 ` [PATCH v3 4/4] mtd: rawnand: micron: support 8/512 on-die ECC Chris Packham
2018-06-20 8:02 ` Boris Brezillon [this message]
2018-06-20 22:22 ` Chris Packham
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=20180620100232.0ad18adc@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