Received: by 2002:ac0:a591:0:0:0:0:0 with SMTP id m17-v6csp2035733imm; Fri, 6 Jul 2018 10:38:14 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdloc5fg6ItgB7lSb8O0DGYNs53UaTOhnxkUFrEG0Fse1nEdq4I55SfdWROYjOlT4cd1snM X-Received: by 2002:a63:175b:: with SMTP id 27-v6mr7033322pgx.31.1530898694028; Fri, 06 Jul 2018 10:38:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530898693; cv=none; d=google.com; s=arc-20160816; b=zSR2SeLj/bgkWTFfF+dQ71dNQ/66iLVEfZtGptGnYZJ0S24rgEFdezRA0o5y7zJ9XD Cv9i7lqDdaBeOKksVJVNm7BEx7S+D/ELq64OxrScChKPBA+5F4Hs1Jgfk/nE3HbMNfRQ jmmkjro1SbL/JxzeRwv39L4lcdX1uHe/17SZn8gIbo3hnijYOOLk3CLpRHbdXgqJG3OD LxIXbLFOFg6ooZphZxTSJRvCkUuappdjpKpS3m6JT3PsbiME6U+Dvy4b0vHZIspXn4hJ leSW/ilACbq+GaTk7xI3VGeXx4JjRJ3HGiypubiQaK1FdhjFCWzxwjxInB5YV3MRyqnH jfJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=1EuZZhSNKksbFF3kT0uIaFrRi8uYCYs8hqudRfozYqQ=; b=zdxoctrNmxtHCzjLQ6mtYmBRdDVYRVDV1fIWu4lApftiELc7n1SjVAXd8oWFSkTqJA JDwPmHfF8tQ5EE2l9lzztYz88zSkgislViEyb9hpobx1tHI8reu05Xvvw2U+I8KnaLQX MkH8s3mxEZ0RHn3wsSAiNBW+xHrg1dc3Yf3W3cgkkTG21TozwV+Dv6UYlGb9b1Wltr8r BzEp41+YIxk3CbSMAp0EDmSTVeqeGHn1nOpFCM0n9rHi4javWzsFt870MP812LT28Lq9 B0Lx6+REKEo799Bsq2fX4KbSAYcO2ehXFzylZzIWd/kCNQwJSwn2K5vksPdDYuFT1ZAg TvDg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k2-v6si8670241plt.374.2018.07.06.10.37.59; Fri, 06 Jul 2018 10:38:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933801AbeGFRhS (ORCPT + 99 others); Fri, 6 Jul 2018 13:37:18 -0400 Received: from mail.bootlin.com ([62.4.15.54]:39268 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932580AbeGFRhR (ORCPT ); Fri, 6 Jul 2018 13:37:17 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id CB1FD2079C; Fri, 6 Jul 2018 19:37:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.0 Received: from bbrezillon (91-160-177-164.subs.proxad.net [91.160.177.164]) by mail.bootlin.com (Postfix) with ESMTPSA id 81E612072D; Fri, 6 Jul 2018 19:37:14 +0200 (CEST) Date: Fri, 6 Jul 2018 19:37:15 +0200 From: Boris Brezillon To: Chris Packham Cc: miquel.raynal@bootlin.com, dwmw2@infradead.org, computersforpeace@gmail.com, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Richard Weinberger , Marek Vasut Subject: Re: [PATCH v6 5/6] mtd: rawnand: micron: support 8/512 on-die ECC Message-ID: <20180706193715.5b2d8bdd@bbrezillon> In-Reply-To: <20180624224448.21872-6-chris.packham@alliedtelesis.co.nz> References: <20180624224448.21872-1-chris.packham@alliedtelesis.co.nz> <20180624224448.21872-6-chris.packham@alliedtelesis.co.nz> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 25 Jun 2018 10:44:47 +1200 Chris Packham 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 > Reviewed-by: Boris Brezillon > --- > 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. > Changes in v4: > - Use a switch statement for handling ECC status > - Update ecc_stats.corrected > Changes in v5: > - Move status checking to different routines for 4/512 and 8/512 assume > the highest number of bit flips for a given status value. > Changes in v6: > - Add review from Boris > > drivers/mtd/nand/raw/nand_micron.c | 100 +++++++++++++++++++++++------ > 1 file changed, 79 insertions(+), 21 deletions(-) > > diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c > index d30bd4df9b12..f83053562925 100644 > --- a/drivers/mtd/nand/raw/nand_micron.c > +++ b/drivers/mtd/nand/raw/nand_micron.c > @@ -18,10 +18,30 @@ > #include > > /* > - * 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. > */ > -#define NAND_STATUS_WRITE_RECOMMENDED BIT(3) > +#define NAND_ECC_STATUS_WRITE_RECOMMENDED BIT(3) > + > +/* > + * 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 1 1 Reserved > + * 1 0 0 1 - 3 errors corrected > + * 1 0 1 Reserved > + * 1 1 0 7 - 8 errors corrected, recommend rewrite > + */ > +#define NAND_ECC_STATUS_MASK (BIT(4) | BIT(3) | BIT(0)) > +#define NAND_ECC_STATUS_UNCORRECTABLE BIT(0) > +#define NAND_ECC_STATUS_4_6_CORRECTED BIT(3) > +#define NAND_ECC_STATUS_1_3_CORRECTED BIT(4) > +#define NAND_ECC_STATUS_7_8_CORRECTED (BIT(4) | BIT(3)) > > struct nand_onfi_vendor_micron { > u8 two_plane_read; > @@ -113,6 +133,54 @@ static int micron_nand_on_die_ecc_setup(struct nand_chip *chip, bool enable) > return nand_set_features(chip, ONFI_FEATURE_ON_DIE_ECC, feature); > } > > + > +static int micron_nand_on_die_ecc_status_4(struct mtd_info *mtd, > + struct nand_chip *chip, u8 status) > +{ > + /* > + * The internal 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 > + * hint the NAND core to rewrite the block. > + */ > + if (status & NAND_STATUS_FAIL) { > + mtd->ecc_stats.failed++; > + } else if (status & NAND_ECC_STATUS_WRITE_RECOMMENDED) { > + mtd->ecc_stats.corrected += chip->ecc.strength; > + return chip->ecc.strength; > + } > + > + return 0; > +} > + > +static int micron_nand_on_die_ecc_status_8(struct mtd_info *mtd, > + struct nand_chip *chip, u8 status) > +{ > + /* > + * With 8/512 we have more information but still don't know precisely > + * how many bit-flips were seen. > + */ > + switch (status & NAND_ECC_STATUS_MASK) { > + case NAND_ECC_STATUS_UNCORRECTABLE: > + mtd->ecc_stats.failed++; > + return 0; > + case NAND_ECC_STATUS_1_3_CORRECTED: > + mtd->ecc_stats.corrected += 3; > + return 3; > + case NAND_ECC_STATUS_4_6_CORRECTED: > + mtd->ecc_stats.corrected += 6; > + /* rewrite recommended */ > + return 6; > + case NAND_ECC_STATUS_7_8_CORRECTED: > + mtd->ecc_stats.corrected += 8; > + /* rewrite recommended */ > + return 8; > + default: > + return 0; > + } > +} > + > static int > micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip, > uint8_t *buf, int oob_required, > @@ -137,19 +205,10 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip, > if (ret) > goto out; > > - if (status & NAND_STATUS_FAIL) { > - mtd->ecc_stats.failed++; > - } else if (status & NAND_STATUS_WRITE_RECOMMENDED) { > - /* > - * The internal 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 > - * hint the NAND core to rewrite the block. > - */ > - mtd->ecc_stats.corrected += chip->ecc.strength; > - max_bitflips = chip->ecc.strength; > - } > + if (chip->ecc.strength == 4) > + max_bitflips = micron_nand_on_die_ecc_status_4(mtd, chip, status); > + else > + max_bitflips = micron_nand_on_die_ecc_status_8(mtd, chip, status); > > ret = nand_read_data_op(chip, buf, mtd->writesize, false); > if (!ret && oob_required) > @@ -240,10 +299,9 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip) > return MICRON_ON_DIE_MANDATORY; > > /* > - * Some Micron NANDs have an on-die ECC of 4/512, some other > - * 8/512. We only support the former. > + * We only support on-die ECC of 4/512 or 8/512 > */ > - if (chip->ecc_strength_ds != 4) > + if (chip->ecc_strength_ds != 4 && chip->ecc_strength_ds != 8) > return MICRON_ON_DIE_UNSUPPORTED; > > return MICRON_ON_DIE_SUPPORTED; > @@ -275,9 +333,9 @@ static int micron_nand_init(struct nand_chip *chip) > return -EINVAL; > } > > - chip->ecc.bytes = 8; > + chip->ecc.bytes = chip->ecc_strength_ds * 2; Just had a quick look at the MT29F1G08ABAFAWP datasheet, and the layout is different: you have all ECC bytes placed at the end of OOB area (64 bytes), and all the free bytes placed at the beginning (64 bytes). You should define a new mtd_ooblayout_ops for this case. > 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;