[PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Martin Kurbanov]

Add support for FORESEE F35SQA002G SPI NAND.
Datasheet:
  https://www.longsys.com/uploads/LM-00006FORESEEF35SQA002GDatasheet_1650183701.pdf

Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com>
---
Changes v2 since v1 at [1]:
  - Drop unneeded comment.

Links:
  [1] https://lore.kernel.org/all/20230929144934.192649-1-mmkurbanov@salutedevices.com/

 drivers/mtd/nand/spi/Makefile  |  2 +-
 drivers/mtd/nand/spi/core.c    |  1 +
 drivers/mtd/nand/spi/foresee.c | 95 ++++++++++++++++++++++++++++++++++
 include/linux/mtd/spinand.h    |  1 +
 4 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mtd/nand/spi/foresee.c

diff --git a/drivers/mtd/nand/spi/Makefile b/drivers/mtd/nand/spi/Makefile
index cd8b66bf7740..19cc77288ebb 100644
--- a/drivers/mtd/nand/spi/Makefile
+++ b/drivers/mtd/nand/spi/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
-spinand-objs := core.o alliancememory.o ato.o esmt.o gigadevice.o macronix.o
+spinand-objs := core.o alliancememory.o ato.o esmt.o foresee.o gigadevice.o macronix.o
 spinand-objs += micron.o paragon.o toshiba.o winbond.o xtx.o
 obj-$(CONFIG_MTD_SPI_NAND) += spinand.o
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 393ff37f0d23..849ccfedbc72 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -940,6 +940,7 @@ static const struct spinand_manufacturer *spinand_manufacturers[] = {
 	&alliancememory_spinand_manufacturer,
 	&ato_spinand_manufacturer,
 	&esmt_c8_spinand_manufacturer,
+	&foresee_spinand_manufacturer,
 	&gigadevice_spinand_manufacturer,
 	&macronix_spinand_manufacturer,
 	&micron_spinand_manufacturer,
diff --git a/drivers/mtd/nand/spi/foresee.c b/drivers/mtd/nand/spi/foresee.c
new file mode 100644
index 000000000000..e0d2d9257045
--- /dev/null
+++ b/drivers/mtd/nand/spi/foresee.c
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023, SberDevices. All Rights Reserved.
+ *
+ * Author: Martin Kurbanov <mmkurbanov@salutedevices.com>
+ */
+
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/mtd/spinand.h>
+
+#define SPINAND_MFR_FORESEE		0xCD
+
+static SPINAND_OP_VARIANTS(read_cache_variants,
+		SPINAND_PAGE_READ_FROM_CACHE_X4_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_X2_OP(0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(true, 0, 1, NULL, 0),
+		SPINAND_PAGE_READ_FROM_CACHE_OP(false, 0, 1, NULL, 0));
+
+static SPINAND_OP_VARIANTS(write_cache_variants,
+		SPINAND_PROG_LOAD_X4(true, 0, NULL, 0),
+		SPINAND_PROG_LOAD(true, 0, NULL, 0));
+
+static SPINAND_OP_VARIANTS(update_cache_variants,
+		SPINAND_PROG_LOAD_X4(false, 0, NULL, 0),
+		SPINAND_PROG_LOAD(false, 0, NULL, 0));
+
+static int f35sqa002g_ooblayout_ecc(struct mtd_info *mtd, int section,
+				    struct mtd_oob_region *region)
+{
+	return -ERANGE;
+}
+
+static int f35sqa002g_ooblayout_free(struct mtd_info *mtd, int section,
+				     struct mtd_oob_region *region)
+{
+	if (section)
+		return -ERANGE;
+
+	/* Reserve 2 bytes for the BBM. */
+	region->offset = 2;
+	region->length = 62;
+
+	return 0;
+}
+
+static const struct mtd_ooblayout_ops f35sqa002g_ooblayout = {
+	.ecc = f35sqa002g_ooblayout_ecc,
+	.free = f35sqa002g_ooblayout_free,
+};
+
+static int f35sqa002g_ecc_get_status(struct spinand_device *spinand, u8 status)
+{
+	struct nand_device *nand = spinand_to_nand(spinand);
+
+	switch (status & STATUS_ECC_MASK) {
+	case STATUS_ECC_NO_BITFLIPS:
+		return 0;
+
+	case STATUS_ECC_HAS_BITFLIPS:
+		return nanddev_get_ecc_conf(nand)->strength;
+
+	default:
+		break;
+	}
+
+	/* More than 1-bit error was detected in one or more sectors and
+	 * cannot be corrected.
+	 */
+	return -EBADMSG;
+}
+
+static const struct spinand_info foresee_spinand_table[] = {
+	SPINAND_INFO("F35SQA002G",
+		     SPINAND_ID(SPINAND_READID_METHOD_OPCODE_DUMMY, 0x72, 0x72),
+		     NAND_MEMORG(1, 2048, 64, 64, 2048, 40, 1, 1, 1),
+		     NAND_ECCREQ(1, 512),
+		     SPINAND_INFO_OP_VARIANTS(&read_cache_variants,
+					      &write_cache_variants,
+					      &update_cache_variants),
+		     SPINAND_HAS_QE_BIT,
+		     SPINAND_ECCINFO(&f35sqa002g_ooblayout,
+				     f35sqa002g_ecc_get_status)),
+};
+
+static const struct spinand_manufacturer_ops foresee_spinand_manuf_ops = {
+};
+
+const struct spinand_manufacturer foresee_spinand_manufacturer = {
+	.id = SPINAND_MFR_FORESEE,
+	.name = "FORESEE",
+	.chips = foresee_spinand_table,
+	.nchips = ARRAY_SIZE(foresee_spinand_table),
+	.ops = &foresee_spinand_manuf_ops,
+};
diff --git a/include/linux/mtd/spinand.h b/include/linux/mtd/spinand.h
index 3e285c09d16d..badb4c1ac079 100644
--- a/include/linux/mtd/spinand.h
+++ b/include/linux/mtd/spinand.h
@@ -263,6 +263,7 @@ struct spinand_manufacturer {
 extern const struct spinand_manufacturer alliancememory_spinand_manufacturer;
 extern const struct spinand_manufacturer ato_spinand_manufacturer;
 extern const struct spinand_manufacturer esmt_c8_spinand_manufacturer;
+extern const struct spinand_manufacturer foresee_spinand_manufacturer;
 extern const struct spinand_manufacturer gigadevice_spinand_manufacturer;
 extern const struct spinand_manufacturer macronix_spinand_manufacturer;
 extern const struct spinand_manufacturer micron_spinand_manufacturer;
-- 
2.40.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Miquel Raynal]

On Mon, 2023-10-02 at 14:04:58 UTC, Martin Kurbanov wrote:
> Add support for FORESEE F35SQA002G SPI NAND.
> Datasheet:
>   https://www.longsys.com/uploads/LM-00006FORESEEF35SQA002GDatasheet_1650183701.pdf
> 
> Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com>

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.

Miquel

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[SkyLake Huang (黃啟澤)]

Hi Miquel/Martin,
About this driver, including F35SQA001G/F35SQA002G parts, I'm concerned
that the driver will always use 32H for update_cache operations, which
means it's not compitable with those SPI controller who can't transmit
2048 bytes (most small-density SPI-NAND's page size nowadays) at one
time.

The following controller's driver seems that they can't transmit 2048
bytes in one transmission:
- spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
- spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
- spi-fsl-qspi.c: 1KB
- spi-hisi-sfc-v3xx.c: 64*6 bytes
- spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
- spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
- spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
- spi-wpcm-fiu.c: 4B

I guess we need to add some check to make sure that F35SQA series work
only with those SPI controllers who can transmit more than 2048
bytes(NAND page size) at one time?

BRs,
Sky
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Miquel Raynal]

Hi Sky,

On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.com> wrote:

> Hi Miquel/Martin,
> About this driver, including F35SQA001G/F35SQA002G parts, I'm concerned
> that the driver will always use 32H for update_cache operations, which
> means it's not compitable with those SPI controller who can't transmit
> 2048 bytes (most small-density SPI-NAND's page size nowadays) at one
> time.
>
> The following controller's driver seems that they can't transmit 2048
> bytes in one transmission:
> - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> - spi-fsl-qspi.c: 1KB
> - spi-hisi-sfc-v3xx.c: 64*6 bytes
> - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> - spi-wpcm-fiu.c: 4B

I believe most of these drivers are still able to send one page of data
without toggling the CS (which is what actually matters, I believe). If
they were broken, they would be broken with all spi memory devices, not
only Foresee's.

> I guess we need to add some check to make sure that F35SQA series work
> only with those SPI controllers who can transmit more than 2048
> bytes(NAND page size) at one time?

There is already a supports_op() hook for that, I believe we are
fine. If however you experience errors, please report them and we'll
look for a solution.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[SkyLake Huang (黃啟澤)]

On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Hi Sky,
> 
> On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
> SkyLake.Huang@mediatek.com> wrote:
> 
> > Hi Miquel/Martin,
> > About this driver, including F35SQA001G/F35SQA002G parts, I'm
> > concerned
> > that the driver will always use 32H for update_cache operations,
> > which
> > means it's not compitable with those SPI controller who can't
> > transmit
> > 2048 bytes (most small-density SPI-NAND's page size nowadays) at
> > one
> > time.
> > 
> > The following controller's driver seems that they can't transmit
> > 2048
> > bytes in one transmission:
> > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> > - spi-fsl-qspi.c: 1KB
> > - spi-hisi-sfc-v3xx.c: 64*6 bytes
> > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> > - spi-wpcm-fiu.c: 4B
> 
> I believe most of these drivers are still able to send one page of
> data
> without toggling the CS (which is what actually matters, I believe).
> If
> they were broken, they would be broken with all spi memory devices,
> not
> only Foresee's.
> 
Hi Miquel,
I think it's not about toggling the CS?

If a SPI controller tries to execute write page and it's capable to
send only 1KB in one transmission, it should transmit data in two
steps: 1st 34H (random program load x4) and 2nd 34H. However, when
F35SQA002G executes 2nd 34H command, it needs to execute 32H first, and
it will clear data transmitted by 1st 34H in NAND flash's cache. This
will cause data corruption. Other SPI-NANDs doesn't need to execute 32H
before 34H.

> > I guess we need to add some check to make sure that F35SQA series
> > work
> > only with those SPI controllers who can transmit more than 2048
> > bytes(NAND page size) at one time?
> 
> There is already a supports_op() hook for that, I believe we are
> fine. If however you experience errors, please report them and we'll
> look for a solution.
> 
> Thanks,
> Miquèl

We can block 32H update_cache opcode in supports_op() hook for those
light SPI controllers(transmittion cap. < 2048 Bytes)? Not sure if
there's a better solution.

Indeed, most SPI controllers support DMA transmission(>2048 Bytes) now,
including our MTK filogic platform. If this doesn't bother other FIFO-
only SPI controllers, I'll take it.

BRs,
Sky
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Miquel Raynal]

On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.com> wrote:

> On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>> 
>> 
>> Hi Sky,
>> 
>> On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
>> SkyLake.Huang@mediatek.com> wrote:
>> 
>> > Hi Miquel/Martin,
>> > About this driver, including F35SQA001G/F35SQA002G parts, I'm
>> > concerned
>> > that the driver will always use 32H for update_cache operations,
>> > which
>> > means it's not compitable with those SPI controller who can't
>> > transmit
>> > 2048 bytes (most small-density SPI-NAND's page size nowadays) at
>> > one
>> > time.
>> > 
>> > The following controller's driver seems that they can't transmit
>> > 2048
>> > bytes in one transmission:
>> > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
>> > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
>> > - spi-fsl-qspi.c: 1KB
>> > - spi-hisi-sfc-v3xx.c: 64*6 bytes
>> > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
>> > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
>> > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
>> > - spi-wpcm-fiu.c: 4B
>> 
>> I believe most of these drivers are still able to send one page of
>> data
>> without toggling the CS (which is what actually matters, I believe).
>> If
>> they were broken, they would be broken with all spi memory devices,
>> not
>> only Foresee's.
>> 
> Hi Miquel,
> I think it's not about toggling the CS?
>
> If a SPI controller tries to execute write page and it's capable to
> send only 1KB in one transmission, it should transmit data in two
> steps: 1st 34H (random program load x4) and 2nd 34H. However, when
> F35SQA002G executes 2nd 34H command, it needs to execute 32H first, and
> it will clear data transmitted by 1st 34H in NAND flash's cache. This
> will cause data corruption. Other SPI-NANDs doesn't need to execute 32H
> before 34H.

Is it really what happens? I'd instead expect the spi controller to
send:
- 34h
- 1k data
- 1k data
...

Why should we repeat the command while we are in the I/O phase?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Chuanhong Guo]

Hello all!

On Wed, Nov 13, 2024 at 5:05 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <SkyLake.Huang@mediatek.com> wrote:
>
> > On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
> >> External email : Please do not click links or open attachments until
> >> you have verified the sender or the content.
> >>
> >>
> >> Hi Sky,
> >>
> >> On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
> >> SkyLake.Huang@mediatek.com> wrote:
> >>
> >> > Hi Miquel/Martin,
> >> > About this driver, including F35SQA001G/F35SQA002G parts, I'm
> >> > concerned
> >> > that the driver will always use 32H for update_cache operations,
> >> > which
> >> > means it's not compitable with those SPI controller who can't
> >> > transmit
> >> > 2048 bytes (most small-density SPI-NAND's page size nowadays) at
> >> > one
> >> > time.
> >> >
> >> > The following controller's driver seems that they can't transmit
> >> > 2048
> >> > bytes in one transmission:
> >> > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> >> > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> >> > - spi-fsl-qspi.c: 1KB
> >> > - spi-hisi-sfc-v3xx.c: 64*6 bytes
> >> > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> >> > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> >> > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> >> > - spi-wpcm-fiu.c: 4B
> >>
> >> I believe most of these drivers are still able to send one page of
> >> data
> >> without toggling the CS (which is what actually matters, I believe).
> >> If
> >> they were broken, they would be broken with all spi memory devices,
> >> not
> >> only Foresee's.
> >>
> > Hi Miquel,
> > I think it's not about toggling the CS?
> >
> > If a SPI controller tries to execute write page and it's capable to
> > send only 1KB in one transmission, it should transmit data in two
> > steps: 1st 34H (random program load x4) and 2nd 34H. However, when
> > F35SQA002G executes 2nd 34H command, it needs to execute 32H first, and

I don't think that's what the datasheet means. I think it needs
02h/32h as the first
command to write page cache, and the subsequent page cache writing can
be done using 84h/34h before the final page program happens. Otherwise the
84h/34h command is just completely broken and useless.
If it actually is broken, we do need additional guards in spinand_write_cache_op
to abort when spi_mem_dirmap_write doesn't return exactly nbytes as requested.

> > it will clear data transmitted by 1st 34H in NAND flash's cache. This
> > will cause data corruption. Other SPI-NANDs doesn't need to execute 32H
> > before 34H.
>
> Is it really what happens? I'd instead expect the spi controller to
> send:
> - 34h
> - 1k data
> - 1k data
> ...
>
> Why should we repeat the command while we are in the I/O phase?

Several SPI-MEM controller don't allow software controlled CS, or for some
other reasons are unable to execute a longer spi-mem op.
spi_mem_dirmap_write returns the actual request size it's able to make,
and spinand_write_to_cache_op use a while loop to split one update_cache
request into multiple ones.

This only works using the Random Program Load instruction (84h/34h)
which preserves the previous written data in the flash data cache.
All current supported flashes are exclusively using 84h/34h as the command
to write the page cache.

Load Program Data(02h/32h) will clear the entire page cache. As a
result, when a request is split as described above, the previous written
data will be cleared, breaking the page cache writing procedure.

We can change write_to_cache_op to use Load Program Data on the
first request. If that doesn't finish writing, use Random Program Load
on subsequent data loading.
-- 
Regards,
Chuanhong Guo

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[Miquel Raynal]

Hello,

> Several SPI-MEM controller don't allow software controlled CS, or for some
> other reasons are unable to execute a longer spi-mem op.
> spi_mem_dirmap_write returns the actual request size it's able to make,
> and spinand_write_to_cache_op use a while loop to split one update_cache
> request into multiple ones.
>
> This only works using the Random Program Load instruction (84h/34h)
> which preserves the previous written data in the flash data cache.
> All current supported flashes are exclusively using 84h/34h as the command
> to write the page cache.
>
> Load Program Data(02h/32h) will clear the entire page cache. As a
> result, when a request is split as described above, the previous written
> data will be cleared, breaking the page cache writing procedure.
>
> We can change write_to_cache_op to use Load Program Data on the
> first request. If that doesn't finish writing, use Random Program Load
> on subsequent data loading.

Sounds reasonable indeed, feel free to send a patch.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2] mtd: spinand: add support for FORESEE F35SQA002G

[SkyLake Huang (黃啟澤)]

On Wed, 2024-11-13 at 18:10 +0800, Chuanhong Guo wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Hello all!
> 
> On Wed, Nov 13, 2024 at 5:05 PM Miquel Raynal <
> miquel.raynal@bootlin.com> wrote:
> > 
> > On 12/11/2024 at 11:25:25 GMT, SkyLake Huang (黃啟澤) <
> > SkyLake.Huang@mediatek.com> wrote:
> > 
> > > On Tue, 2024-11-12 at 11:48 +0100, Miquel Raynal wrote:
> > > > External email : Please do not click links or open attachments
> > > > until
> > > > you have verified the sender or the content.
> > > > 
> > > > 
> > > > Hi Sky,
> > > > 
> > > > On 12/11/2024 at 10:08:31 GMT, SkyLake Huang (黃啟澤) <
> > > > SkyLake.Huang@mediatek.com> wrote:
> > > > 
> > > > > Hi Miquel/Martin,
> > > > > About this driver, including F35SQA001G/F35SQA002G parts, I'm
> > > > > concerned
> > > > > that the driver will always use 32H for update_cache
> > > > > operations,
> > > > > which
> > > > > means it's not compitable with those SPI controller who can't
> > > > > transmit
> > > > > 2048 bytes (most small-density SPI-NAND's page size nowadays)
> > > > > at
> > > > > one
> > > > > time.
> > > > > 
> > > > > The following controller's driver seems that they can't
> > > > > transmit
> > > > > 2048
> > > > > bytes in one transmission:
> > > > > - spi-amd.c: 64 bytes (AMD_SPI_MAX_DATA)
> > > > > - spi-amlogic-spifc-a1.c: 512 bytes (SPIFC_A1_BUFFER_SIZE)
> > > > > - spi-fsl-qspi.c: 1KB
> > > > > - spi-hisi-sfc-v3xx.c: 64*6 bytes
> > > > > - spi-intel.c: 64 bytes (INTEL_SPI_FIFO_SZ)
> > > > > - spi-microchip-core-qspi.c: 256 bytesc (MAX_DATA_CMD_LEN)
> > > > > - spi-nxp-fspi.c: TX:1KB, RX: 512B in FIFO mode
> > > > > - spi-wpcm-fiu.c: 4B
> > > > 
> > > > I believe most of these drivers are still able to send one page
> > > > of
> > > > data
> > > > without toggling the CS (which is what actually matters, I
> > > > believe).
> > > > If
> > > > they were broken, they would be broken with all spi memory
> > > > devices,
> > > > not
> > > > only Foresee's.
> > > > 
> > > 
> > > Hi Miquel,
> > > I think it's not about toggling the CS?
> > > 
> > > If a SPI controller tries to execute write page and it's capable
> > > to
> > > send only 1KB in one transmission, it should transmit data in two
> > > steps: 1st 34H (random program load x4) and 2nd 34H. However,
> > > when
> > > F35SQA002G executes 2nd 34H command, it needs to execute 32H
> > > first, and
> 
> I don't think that's what the datasheet means. I think it needs
> 02h/32h as the first
> command to write page cache, and the subsequent page cache writing
> can
> be done using 84h/34h before the final page program happens.
> Otherwise the
> 84h/34h command is just completely broken and useless.
> If it actually is broken, we do need additional guards in
> spinand_write_cache_op
> to abort when spi_mem_dirmap_write doesn't return exactly nbytes as
> requested.
> 
Confirm with Foresee and yes you're right XD

> > > it will clear data transmitted by 1st 34H in NAND flash's cache.
> > > This
> > > will cause data corruption. Other SPI-NANDs doesn't need to
> > > execute 32H
> > > before 34H.
> > 
> > Is it really what happens? I'd instead expect the spi controller to
> > send:
> > - 34h
> > - 1k data
> > - 1k data
> > ...
> > 
> > Why should we repeat the command while we are in the I/O phase?
> 
> Several SPI-MEM controller don't allow software controlled CS, or for
> some
> other reasons are unable to execute a longer spi-mem op.
> spi_mem_dirmap_write returns the actual request size it's able to
> make,
> and spinand_write_to_cache_op use a while loop to split one
> update_cache
> request into multiple ones.
> 
> This only works using the Random Program Load instruction (84h/34h)
> which preserves the previous written data in the flash data cache.
> All current supported flashes are exclusively using 84h/34h as the
> command
> to write the page cache.
> 
> Load Program Data(02h/32h) will clear the entire page cache. As a
> result, when a request is split as described above, the previous
> written
> data will be cleared, breaking the page cache writing procedure.
> 
> We can change write_to_cache_op to use Load Program Data on the
> first request. If that doesn't finish writing, use Random Program
> Load
> on subsequent data loading.
> --
> Regards,
> Chuanhong Guo

I observe that exec_op() in drivers/spi/spi-mt65xx.c on our platform
will issue the following commands once I limit its capability in
1024Bytes: (try to write 1 page)
- 34H
- addr
- 1020KB (1024KB - 1 byte opcode - 3 bytes addr)
- 34H
- addr
- 1020KB (1024KB - 1 byte opcode - 3 bytes addr)
- 34H
- addr
- 72KB

Is it possible to send 34H, 1K, 1K with current nbytes loop in
spinand_write_to_cache_op()? With which SPI controller?

I submit a patch according to this discussion, anyway.

https://lore.kernel.org/linux-mtd/20241119093949.3014-1-SkyLake.Huang@mediatek.com/

BRs,
Sky
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/