From: Sky Huang <SkyLake.Huang@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
Daniel Golle <daniel@makrotopia.org>,
Chia-Lin Kao <acelan.kao@canonical.com>,
"Cheng Ming Lin" <chengminglin@mxic.com.tw>,
Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
Pratyush Yadav <pratyush@kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Cc: Steven Liu <Steven.Liu@mediatek.com>,
Sky Huang <skylake.huang@mediatek.com>
Subject: [PATCH nand/next] mtd: nand: spi: Use write_cache first and then update_cache in write operation
Date: Tue, 19 Nov 2024 17:39:49 +0800 [thread overview]
Message-ID: <20241119093949.3014-1-SkyLake.Huang@mediatek.com> (raw)
From: Sky Huang <skylake.huang@mediatek.com>
According to discussion with Miquel Raynal <miquel.raynal@bootlin.com>
and Chuanhong Guo <gch981213@gmail.com> on FORESEE F35SQA002G patch,
Chuanhong recommmends that we can use the following sequence in
spinand_write_to_cache_op():
x1 mode:
02H(program data load) -> 84H(random program data load) -> 84H ...
x4 mode:
32H(program data load x4) -> 34H(random program data load x4) -> 34H ...
02H or 32H commands will clear cache buffer on SPI-NAND and load
data to it. For those SPI controllers which can't finish transmission
in single step, 84H or 34H will be triggered for the rest data.
We observe that some current SPI-NANDs, including FORESEE F35SQA001G and
F35SQA002G, must use 02H or 32H to reset cache buffer in flash before
using 84H or 34H. Or users may encounter program failure issue. This issue
is not always reproducible, but it may occur and cause system instability.
This sequence should work on all SPI-NANDs nowadays. I also check with
Foresee that the sequence can solve the above program failure issue.
On my test platform (MT7988), SPI driver is drivers/spi/spi-mt65xx.c.
And I limit MTK_SPI_IPM_PACKET_SIZE to SZ_1K to simulate lightweight SPI
controller which can only transmit 1024 bytes.
The test step is the following:
- mtd erase /dev/mtd2
- dd if=/dev/zero bs=2048 count=1 | tr '\0' '\xA5' > output.bin
- mtd write output.bin /dev/mtd2
Before applying this patch, write operation uses only 34H(update_cache):
[78.937720] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xa5
[78.945297] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xa5
[78.954251] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xa5
[78.962966] OP code: 0x10, addr val: 0x300
[78.968816] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
[78.977233] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
[78.985124] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
[78.992527] OP code: 0x10, addr val: 0x301
[78.996981] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
[79.004416] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
[79.012031] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
[79.019435] OP code: 0x10, addr val: 0x302
...
After applying this patch, write operation will use 32H and then 34H:
[ 5380.911269] OP code: 0x32, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xa5
[ 5380.918889] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xa5
[ 5380.927836] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xa5
[ 5380.936558] OP code: 0x10, addr val: 0x300
[ 5380.942411] OP code: 0x32, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
[ 5380.950831] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
[ 5380.958722] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
[ 5380.966129] OP code: 0x10, addr val: 0x301
[ 5380.970376] OP code: 0x32, addr val: 0x0, data nbytes: 1020, data 1st byte: 0xff
[ 5380.977810] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data 1st byte: 0xff
[ 5380.985424] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1st byte: 0xff
[ 5380.992826] OP code: 0x10, addr val: 0x302
...
Signed-off-by: Sky Huang <skylake.huang@mediatek.com>
---
drivers/mtd/nand/spi/core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index b1df7f627161..351bd14d8e06 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -506,7 +506,10 @@ static int spinand_write_to_cache_op(struct spinand_device *spinand,
nbytes -= ret;
column += ret;
buf += ret;
+
+ wdesc->info.op_tmpl = *spinand->op_templates.update_cache;
}
+ wdesc->info.op_tmpl = *spinand->op_templates.write_cache;
return 0;
}
@@ -1037,7 +1040,7 @@ static int spinand_create_dirmap(struct spinand_device *spinand,
/* The plane number is passed in MSB just above the column address */
info.offset = plane << fls(nand->memorg.pagesize);
- info.op_tmpl = *spinand->op_templates.update_cache;
+ info.op_tmpl = *spinand->op_templates.write_cache;
desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
spinand->spimem, &info);
if (IS_ERR(desc))
@@ -1060,7 +1063,7 @@ static int spinand_create_dirmap(struct spinand_device *spinand,
return 0;
}
- info.op_tmpl = *spinand->op_templates.update_cache;
+ info.op_tmpl = *spinand->op_templates.write_cache;
info.op_tmpl.data.ecc = true;
desc = devm_spi_mem_dirmap_create(&spinand->spimem->spi->dev,
spinand->spimem, &info);
--
2.45.2
next reply other threads:[~2024-11-19 9:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-19 9:39 Sky Huang [this message]
2024-12-05 15:32 ` [PATCH nand/next] mtd: nand: spi: Use write_cache first and then update_cache in write operation Miquel Raynal
2025-04-22 1:38 ` Chuanhong Guo
2025-04-29 8:15 ` Miquel Raynal
2025-04-29 11:58 ` Chuanhong Guo
2025-05-26 12:25 ` 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=20241119093949.3014-1-SkyLake.Huang@mediatek.com \
--to=skylake.huang@mediatek.com \
--cc=Steven.Liu@mediatek.com \
--cc=acelan.kao@canonical.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chengminglin@mxic.com.tw \
--cc=christophe.jaillet@wanadoo.fr \
--cc=daniel@makrotopia.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=matthias.bgg@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--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