From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: linux-spi@vger.kernel.org, Mark Brown <broonie@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Roger Quadros <rogerq@kernel.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Cai Huoqing <cai.huoqing@linux.dev>,
Florian Fainelli <f.fainelli@gmail.com>,
Colin Ian King <colin.king@intel.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Paul Cercueil <paul@crapouillou.net>,
Pratyush Yadav <p.yadav@ti.com>, Yu Kuai <yukuai3@huawei.com>,
devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS),
linux-arm-kernel@lists.infradead.org (moderated
list:ARM/Mediatek SoC support),
linux-mediatek@lists.infradead.org (moderated list:ARM/Mediatek
SoC support), linux-kernel@vger.kernel.org (open list),
linux-mtd@lists.infradead.org (open list:NAND FLASH SUBSYSTEM)
Subject: Re: [PATCH v2 2/5] spi: add driver for MTK SPI NAND Flash Interface
Date: Mon, 4 Apr 2022 09:59:37 +0200 [thread overview]
Message-ID: <20220404095937.20089db7@xps13> (raw)
In-Reply-To: <20220404040153.1509966-3-gch981213@gmail.com>
Hi Chuanhong,
gch981213@gmail.com wrote on Mon, 4 Apr 2022 12:01:50 +0800:
> This driver implements support for the SPI-NAND mode of MTK NAND Flash
> Interface as a SPI-MEM controller with piplined ECC capability.
>
> Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
> ---
>
> Change since v1:
> fix CI warnings
>
> drivers/spi/Kconfig | 10 +
> drivers/spi/Makefile | 1 +
> drivers/spi/spi-mtk-snfi.c | 1351 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 1362 insertions(+)
> create mode 100644 drivers/spi/spi-mtk-snfi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index d2815eb361c0..739eec7d0c15 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -590,6 +590,16 @@ config SPI_MTK_NOR
> SPI interface as well as several SPI NOR specific instructions
> via SPI MEM interface.
>
> +config SPI_MTK_SNFI
> + tristate "MediaTek SPI NAND Flash Interface"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on MTD_NAND_ECC_MEDIATEK
> + help
> + This enables support for SPI-NAND mode on the MediaTek NAND
> + Flash Interface found on MediaTek ARM SoCs. This controller
> + is implemented as a SPI-MEM controller with pipelined ECC
> + capcability.
> +
> config SPI_NPCM_FIU
> tristate "Nuvoton NPCM FLASH Interface Unit"
> depends on ARCH_NPCM || COMPILE_TEST
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index 3aa28ed3f761..51541ff17e67 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -76,6 +76,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o
> obj-$(CONFIG_SPI_MT65XX) += spi-mt65xx.o
> obj-$(CONFIG_SPI_MT7621) += spi-mt7621.o
> obj-$(CONFIG_SPI_MTK_NOR) += spi-mtk-nor.o
> +obj-$(CONFIG_SPI_MTK_SNFI) += spi-mtk-snfi.o
> obj-$(CONFIG_SPI_MXIC) += spi-mxic.o
> obj-$(CONFIG_SPI_MXS) += spi-mxs.o
> obj-$(CONFIG_SPI_NPCM_FIU) += spi-npcm-fiu.o
> diff --git a/drivers/spi/spi-mtk-snfi.c b/drivers/spi/spi-mtk-snfi.c
> new file mode 100644
> index 000000000000..e8f8f30bd7ee
> --- /dev/null
> +++ b/drivers/spi/spi-mtk-snfi.c
[...]
> +static struct mtk_snand *nand_to_mtk_snand(struct nand_device *nand)
> +{
> + struct nand_ecc_engine *eng = nand->ecc.engine;
> +
> + return container_of(eng, struct mtk_snand, ecc_eng);
> +}
> +
> +static inline int snand_prepare_bouncebuf(struct mtk_snand *snf, size_t size)
> +{
> + if (snf->buf_len >= size)
> + return 0;
> + if (snf->buf)
> + dmam_free_coherent(snf->dev, snf->buf_len, snf->buf,
> + snf->buf_dma);
Can't we use a single coherent buffer once for all?
> + snf->buf =
> + dmam_alloc_coherent(snf->dev, size, &snf->buf_dma, GFP_KERNEL);
> + if (!snf->buf)
> + return -ENOMEM;
> + snf->buf_len = size;
> + memset(snf->buf, 0xff, snf->buf_len);
> + return 0;
> +}
> +
[...]
> +static int mtk_snand_ecc_init_ctx(struct nand_device *nand)
> +{
> + struct mtk_snand *snf = nand_to_mtk_snand(nand);
> + struct nand_ecc_props *conf = &nand->ecc.ctx.conf;
> + struct mtd_info *mtd = nanddev_to_mtd(nand);
> + int ret;
> +
> + ret = mtk_snand_setup_pagefmt(snf, nand->memorg.pagesize,
> + nand->memorg.oobsize);
> + if (ret)
> + return ret;
> +
> + mtd_set_ooblayout(mtd, &mtk_snand_ooblayout);
> +
> + // This driver ignores any ECC capability configured by user or
> + // requested by the nand chip because the BootROM and MTK bootloader
> + // expects the page format to be the exact one as calculated in
> + // setup_pagefmt.
I don't like this :)
I understand that the boot partition might have specific constraints,
but other partitions (or if we don't use the NAND to boot?) should
probably be usable with other ECC schemes.
> + conf->step_size = snf->caps->sector_size;
> + conf->strength = snf->ecc_cfg.strength;
> +
> + return 0;
> +}
> +
> +static int mtk_snand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + struct mtk_snand *snf = nand_to_mtk_snand(nand);
> + int ret;
> +
> + ret = mtk_snand_setup_pagefmt(snf, nand->memorg.pagesize,
> + nand->memorg.oobsize);
> + if (ret)
> + return ret;
> + snf->autofmt = true;
> + return 0;
> +}
> +
> +static int mtk_snand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + struct mtk_snand *snf = nand_to_mtk_snand(nand);
> + struct mtd_info *mtd = nanddev_to_mtd(nand);
> +
> + snf->autofmt = false;
> + if ((req->mode == MTD_OPS_RAW) || (req->type != NAND_PAGE_READ))
> + return 0;
> +
> + if (snf->ecc_stats.failed)
> + mtd->ecc_stats.failed += snf->ecc_stats.failed;
> + mtd->ecc_stats.corrected += snf->ecc_stats.corrected;
> + return snf->ecc_stats.failed ? -EBADMSG : snf->ecc_stats.bitflips;
Did you verify that nandbiterrs -i succeeds?
> +}
> +
> +static struct nand_ecc_engine_ops mtk_snfi_ecc_engine_ops = {
> + .init_ctx = mtk_snand_ecc_init_ctx,
> + .prepare_io_req = mtk_snand_ecc_prepare_io_req,
> + .finish_io_req = mtk_snand_ecc_finish_io_req,
I believe you need to take care of the bounce buffer in the exit path?
> +};
> +
> +static void mtk_snand_read_fdm(struct mtk_snand *snf, uint8_t *buf)
> +{
> + uint32_t vall, valm;
> + uint8_t *oobptr = buf;
> + int i, j;
> +
> + for (i = 0; i < snf->nfi_cfg.nsectors; i++) {
> + vall = nfi_read32(snf, NFI_FDML(i));
> + valm = nfi_read32(snf, NFI_FDMM(i));
> +
> + for (j = 0; j < snf->caps->fdm_size; j++)
> + oobptr[j] = (j >= 4 ? valm : vall) >> ((j % 4) * 8);
> +
> + oobptr += snf->caps->fdm_size;
> + }
> +}
Thanks,
Miquèl
next prev parent reply other threads:[~2022-04-04 7:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-04 4:01 [PATCH v2 0/5] spi: add support for Mediatek SPI-NAND controller Chuanhong Guo
2022-04-04 4:01 ` [PATCH v2 1/5] mtd: nand: make mtk_ecc.c a separated module Chuanhong Guo
2022-04-04 4:01 ` [PATCH v2 2/5] spi: add driver for MTK SPI NAND Flash Interface Chuanhong Guo
2022-04-04 7:59 ` Miquel Raynal [this message]
2022-04-04 9:13 ` Chuanhong Guo
2022-04-04 9:17 ` Chuanhong Guo
2022-04-04 10:28 ` Miquel Raynal
2022-04-04 10:54 ` Chuanhong Guo
2022-04-04 4:01 ` [PATCH v2 3/5] mtd: nand: mtk-ecc: also parse nand-ecc-engine if available Chuanhong Guo
2022-04-04 4:01 ` [PATCH v2 4/5] dt-bindings: spi: add binding doc for spi-mtk-snfi Chuanhong Guo
2022-04-04 13:49 ` Krzysztof Kozlowski
2022-04-04 4:01 ` [PATCH v2 5/5] arm64: dts: mediatek: add mtk-snfi for mt7622 Chuanhong Guo
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=20220404095937.20089db7@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=broonie@kernel.org \
--cc=cai.huoqing@linux.dev \
--cc=colin.king@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=gch981213@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=p.yadav@ti.com \
--cc=paul@crapouillou.net \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=rogerq@kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=vigneshr@ti.com \
--cc=wsa+renesas@sang-engineering.com \
--cc=yukuai3@huawei.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).