linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Vignesh Raghavendra <vigneshr@ti.com>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>,
	Julien Su <juliensu@mxic.com.tw>,
	Schrempf Frieder <frieder.schrempf@kontron.de>,
	Paul Cercueil <paul@crapouillou.net>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	linux-mtd@lists.infradead.org,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Mason Yang <masonccyang@mxic.com.tw>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 14/40] mtd: nand: Introduce the ECC engine abstraction
Date: Thu, 19 Sep 2019 21:31:14 +0200	[thread overview]
Message-ID: <20190919193141.7865-15-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20190919193141.7865-1-miquel.raynal@bootlin.com>

Create a generic ECC engine object.

Later the ecc.c file will receive more generic code coming from
the raw NAND specific part. This is a base to instantiate ECC engine
objects.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
 drivers/mtd/nand/Kconfig  |   7 ++
 drivers/mtd/nand/Makefile |   2 +
 drivers/mtd/nand/ecc.c    | 138 ++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/nand.h  |  69 +++++++++++++++++++
 4 files changed, 216 insertions(+)
 create mode 100644 drivers/mtd/nand/ecc.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c1a45b071165..a4478ffa279d 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
 source "drivers/mtd/nand/raw/Kconfig"
 source "drivers/mtd/nand/spi/Kconfig"
 
+menu "ECC engine support"
+
+config MTD_NAND_ECC
+	bool
+
+endmenu
+
 endmenu
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 7ecd80c0a66e..981372953b56 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
 obj-y	+= onenand/
 obj-y	+= raw/
 obj-y	+= spi/
+
+nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
new file mode 100644
index 000000000000..4c7943ddf2cc
--- /dev/null
+++ b/drivers/mtd/nand/ecc.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Generic Error-Correcting Code (ECC) engine
+ *
+ * Copyright (C) 2019 Macronix
+ * Author:
+ *     Miquèl RAYNAL <miquel.raynal@bootlin.com>
+ *
+ *
+ * This file describes the abstraction of any NAND ECC engine. It has been
+ * designed to fit most cases, including parallel NANDs and SPI-NANDs.
+ *
+ * There are three main situations where instantiating this ECC engine makes
+ * sense:
+ *   - "external": The ECC engine is outside the NAND pipeline, typically this
+ *                 is a software ECC engine. One can also imagine a generic
+ *                 hardware ECC engine which would be an IP itself. Interacting
+ *                 with a SPI-NAND device without on-die ECC could be achieved
+ *                 thanks to the use of such external engine.
+ *   - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
+ *                  controller's side. This is the case of most of the raw NAND
+ *                  controllers. These controllers usually embed an hardware ECC
+ *                  engine which is managed thanks to the same register set as
+ *                  the controller's.
+ *   - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
+ *              Some NAND chips can correct themselves the data. The on-die
+ *              correction can be enabled, disabled and the status of the
+ *              correction after a read may be retrieved with a NAND command
+ *              (may be vendor specific).
+ *
+ * Besides the initial setup and final cleanups, the interfaces are rather
+ * simple:
+ *   - "prepare": Prepare an I/O request, check the ECC engine is enabled or
+ *                disabled as requested before the I/O. In case of software
+ *                correction, this step may involve to derive the ECC bytes and
+ *                place them in the OOB area before a write.
+ *   - "finish": Finish an I/O request, check the status of the operation ie.
+ *               the data validity in case of a read (report to the upper layer
+ *               any bitflip/errors).
+ *
+ * Both prepare/finish callbacks are supposed to enclose I/O request and will
+ * behave differently depending on the desired correction:
+ *   - "raw": Correction disabled
+ *   - "ecc": Correction enabled
+ *
+ * The request direction is impacting the logic as well:
+ *   - "read": Load data from the NAND chip
+ *   - "write": Store data in the NAND chip
+ *
+ * Mixing all this combinations together gives the following behavior.
+ *
+ * ["external" ECC engine]
+ *   - external + prepare + raw + read: do nothing
+ *   - external + finish  + raw + read: do nothing
+ *   - external + prepare + raw + write: do nothing
+ *   - external + finish  + raw + write: do nothing
+ *   - external + prepare + ecc + read: do nothing
+ *   - external + finish  + ecc + read: calculate expected ECC bytes, extract
+ *                                      ECC bytes from OOB buffer, correct
+ *                                      and report any bitflip/error
+ *   - external + prepare + ecc + write: calculate ECC bytes and store them at
+ *                                       the right place in the OOB buffer based
+ *                                       on the OOB layout
+ *   - external + finish  + ecc + write: do nothing
+ *
+ * ["pipelined" ECC engine]
+ *   - pipelined + prepare + raw + read: disable the controller's ECC engine if
+ *                                       activated
+ *   - pipelined + finish  + raw + read: do nothing
+ *   - pipelined + prepare + raw + write: disable the controller's ECC engine if
+ *                                        activated
+ *   - pipelined + finish  + raw + write: do nothing
+ *   - pipelined + prepare + ecc + read: enable the controller's ECC engine if
+ *                                       deactivated
+ *   - pipelined + finish  + ecc + read: check the status, report any
+ *                                       error/bitflip
+ *   - pipelined + prepare + ecc + write: enable the controller's ECC engine if
+ *                                        deactivated
+ *   - pipelined + finish  + ecc + write: do nothing
+ *
+ * ["ondie" ECC engine]
+ *   - ondie + prepare + raw + read: send commands to disable the on-chip ECC
+ *                                   engine if activated
+ *   - ondie + finish  + raw + read: do nothing
+ *   - ondie + prepare + raw + write: send commands to disable the on-chip ECC
+ *                                    engine if activated
+ *   - ondie + finish  + raw + write: do nothing
+ *   - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
+ *                                   engine if deactivated
+ *   - ondie + finish  + ecc + read: send commands to check the status, report
+ *                                   any error/bitflip
+ *   - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
+ *                                    engine if deactivated
+ *   - ondie + finish  + ecc + write: do nothing
+ */
+
+#include <linux/module.h>
+#include <linux/mtd/nand.h>
+
+int nand_ecc_init_ctx(struct nand_device *nand)
+{
+	if (!nand->ecc.engine->ops->init_ctx)
+		return 0;
+
+	return nand->ecc.engine->ops->init_ctx(nand);
+}
+EXPORT_SYMBOL(nand_ecc_init_ctx);
+
+void nand_ecc_cleanup_ctx(struct nand_device *nand)
+{
+	if (nand->ecc.engine->ops->cleanup_ctx)
+		nand->ecc.engine->ops->cleanup_ctx(nand);
+}
+EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
+
+int nand_ecc_prepare_io_req(struct nand_device *nand,
+			    struct nand_page_io_req *req, void *oobbuf)
+{
+	if (!nand->ecc.engine->ops->prepare_io_req)
+		return 0;
+
+	return nand->ecc.engine->ops->prepare_io_req(nand, req, oobbuf);
+}
+EXPORT_SYMBOL(nand_ecc_prepare_io_req);
+
+int nand_ecc_finish_io_req(struct nand_device *nand,
+			   struct nand_page_io_req *req, void *oobbuf)
+{
+	if (!nand->ecc.engine->ops->finish_io_req)
+		return 0;
+
+	return nand->ecc.engine->ops->finish_io_req(nand, req, oobbuf);
+}
+EXPORT_SYMBOL(nand_ecc_finish_io_req);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
+MODULE_DESCRIPTION("Generic ECC engine");
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 11cd7cc81a7a..a3a86bae5fb7 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -177,6 +177,75 @@ struct nand_ops {
 	bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
 };
 
+/**
+ * struct nand_ecc_context - Context for the ECC engine
+ * @conf: basic ECC engine parameters
+ * @total: Total number of bytes used for storing ECC codes, this is used by
+ *         generic OOB layouts
+ * @priv: ECC engine driver private data
+ */
+struct nand_ecc_context {
+	struct nand_ecc_props conf;
+	unsigned int total;
+	void *priv;
+};
+
+/**
+ * struct nand_ecc_engine_ops - Generic ECC engine operations
+ * @init_ctx: given a desired user configuration for the pointed NAND device,
+ *            requests the ECC engine driver to setup a configuration with
+ *            values it supports.
+ * @cleanup_ctx: clean the context initialized by @init_ctx.
+ * @prepare_io_req: is called before reading/writing a page to prepare the I/O
+ *                  request to be performed with ECC correction.
+ * @finish_io_req: is called after reading/writing a page to terminate the I/O
+ *                 request and ensure proper ECC correction.
+ */
+struct nand_ecc_engine_ops {
+	int (*init_ctx)(struct nand_device *nand);
+	void (*cleanup_ctx)(struct nand_device *nand);
+	int (*prepare_io_req)(struct nand_device *nand,
+			      struct nand_page_io_req *req,
+			      void *oobbuf);
+	int (*finish_io_req)(struct nand_device *nand,
+			     struct nand_page_io_req *req,
+			     void *oobbuf);
+};
+
+/**
+ * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
+ * @ops: ECC engine operations
+ */
+struct nand_ecc_engine {
+	struct nand_ecc_engine_ops *ops;
+};
+
+int nand_ecc_init_ctx(struct nand_device *nand);
+void nand_ecc_cleanup_ctx(struct nand_device *nand);
+int nand_ecc_prepare_io_req(struct nand_device *nand,
+			    struct nand_page_io_req *req, void *oobbuf);
+int nand_ecc_finish_io_req(struct nand_device *nand,
+			   struct nand_page_io_req *req, void *oobbuf);
+
+/**
+ * struct nand_ecc - High-level ECC object
+ * @defaults: Default values, depend on the underlying subsystem
+ * @requirements: ECC requirements from the NAND chip perspective
+ * @user_conf: User desires in terms of ECC parameters
+ * @ctx: ECC context for the ECC engine, derived from the device @requirements
+ *       the @user_conf and the @defaults
+ * @ondie_engine: On-die ECC engine reference, if any
+ * @engine: ECC engine actually bound
+ */
+struct nand_ecc {
+	struct nand_ecc_props defaults;
+	struct nand_ecc_props requirements;
+	struct nand_ecc_props user_conf;
+	struct nand_ecc_context ctx;
+	struct nand_ecc_engine *ondie_engine;
+	struct nand_ecc_engine *engine;
+};
+
 /**
  * struct nand_device - NAND device
  * @mtd: MTD instance attached to the NAND device
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-09-19 19:44 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 19:31 [PATCH v3 00/40] Introduce the generic ECC engine abstraction Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 01/40] mtd: rawnand: Avoid a typedef Miquel Raynal
2019-10-12  8:41   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 02/40] mtd: rawnand: Add an invalid ECC mode to discriminate with valid ones Miquel Raynal
2019-10-12  8:48   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 03/40] mtd: rawnand: Create a new enumeration to describe OOB placement Miquel Raynal
2019-10-12  9:02   ` Boris Brezillon
2019-10-12  9:07     ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 04/40] mtd: rawnand: Separate the ECC engine type and the " Miquel Raynal
2019-10-12  9:05   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 05/40] mtd: rawnand: Create a new enumeration to describe properly ECC types Miquel Raynal
2019-10-12  9:14   ` Boris Brezillon
2020-01-15 20:58     ` Miquel Raynal
2019-10-12  9:55   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 06/40] mtd: rawnand: Use the new ECC engine type enumeration Miquel Raynal
2019-10-12  9:15   ` Boris Brezillon
2019-10-12  9:17   ` Boris Brezillon
2019-10-12  9:28   ` Boris Brezillon
2020-01-15 10:33     ` Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 07/40] mtd: rawnand: Drop the legacy ECC " Miquel Raynal
2019-10-12  9:29   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 08/40] mtd: nand: Move nand_device forward declaration to the top Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 09/40] mtd: nand: Add an extra level in the Kconfig hierarchy Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 10/40] mtd: nand: Drop useless 'depends on' in Kconfig Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 11/40] mtd: nand: Add a NAND page I/O request type Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 12/40] mtd: nand: Rename a core structure Miquel Raynal
2019-10-12  9:35   ` Boris Brezillon
2020-01-16  8:53     ` Miquel Raynal
2020-01-16  9:12       ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 13/40] mtd: nand: Add more parameters to the nand_ecc_props structure Miquel Raynal
2019-10-12  9:37   ` Boris Brezillon
2020-01-16  8:59     ` Miquel Raynal
2019-09-19 19:31 ` Miquel Raynal [this message]
2019-09-19 19:31 ` [PATCH v3 15/40] mtd: nand: Convert the generic NAND layer to the generic ECC framework Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 16/40] mtd: Fix typo in mtd_ooblayout_set_databytes() description Miquel Raynal
2019-10-12 10:58   ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 17/40] mtd: nand: Move standard OOB layouts to the generic ECC core Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 18/40] mtd: nand: Move ECC specific functions to the " Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 19/40] mtd: nand: ecc: Turn the software BCH implementation generic Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 20/40] mtd: rawnand: Get rid of chip->ecc.priv Miquel Raynal
2019-09-20  6:18   ` Maxime Ripard
2019-09-19 19:31 ` [PATCH v3 21/40] mtd: nand: ecc: Move Hamming code to the generic NAND layer Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 22/40] mtd: nand: ecc: Clarify the software Hamming introductory line Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 23/40] mtd: nand: ecc: Turn the software Hamming implementation generic Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 24/40] mtd: nand: Remove useless include about software Hamming ECC Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 25/40] mtd: nand: ecc: Let the software Hamming ECC engine be unselected Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 26/40] mtd: nand: ecc: Create the software BCH engine instance Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 27/40] mtd: nand: ecc: Create the software Hamming " Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 28/40] mtd: nand: Let software ECC engines be retrieved from the NAND core Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 29/40] mtd: spinand: Fix typo in comment Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 30/40] mtd: spinand: Move ECC related definitions earlier in the driver Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 31/40] mtd: spinand: Instantiate a SPI-NAND on-die ECC engine Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 32/40] mtd: nand: Let on-die ECC engines be retrieved from the NAND core Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 33/40] mtd: rawnand: Fill a default ECC provider/algorithm Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 34/40] mtd: spinand: " Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 35/40] mtd: nand: Add helpers to manage ECC engines and configurations Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 36/40] mtd: spinand: Use the external ECC engine logic Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 37/40] mtd: spinand: Propagate ECC information to the MTD structure Miquel Raynal
2020-02-17 13:27   ` Emil Lenngren
2020-02-17 13:31     ` Boris Brezillon
2019-09-19 19:31 ` [PATCH v3 38/40] mtd: spinand: Allow the case where there is no ECC engine Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 39/40] mtd: spinand: Fix OOB read Miquel Raynal
2019-09-19 19:31 ` [PATCH v3 40/40] mtd: nand: ecc: Add infrastructure to support hardware engines Miquel Raynal

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=20190919193141.7865-15-miquel.raynal@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=boris.brezillon@collabora.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=frieder.schrempf@kontron.de \
    --cc=juliensu@mxic.com.tw \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=masonccyang@mxic.com.tw \
    --cc=paul@crapouillou.net \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vigneshr@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 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).