Skip to contentSkip to conversation

mtd: rawnand: Non ONFI specialized timing support

PATCH In review Rickard Andersson 3 participants 4 messages Apr 22, 2020 – May 14, 2020

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 mtd: rawnand: Non ONFI specialized timing support

From: Rickard x Andersson <[email protected]>

The Kioxia/Toshiba TH58NVG2S3HBAI4 NAND memory is not a ONFI compliant memory. The timings of that memory are quite close to ONFI mode 4 but is breaking that spec.

This patch adds a special table with timings that can be used for non ONFI memories.

Erase block read speed is increased from 6739 KiB/s to 13260 KiB/s. Erase block write speed is increased from 3004 KiB/s to 3872 KiB/s.

Tested on IMX6ULL which has a NAND controller supporting EDO mode.

---
 drivers/mtd/nand/raw/internals.h    |  3 +-
 drivers/mtd/nand/raw/nand_base.c    | 73 +++++++++++++++++++++++++++++++++----
 drivers/mtd/nand/raw/nand_ids.c     |  4 ++
 drivers/mtd/nand/raw/nand_timings.c | 66 +++++++++++++++++++++++++++++++--
 include/linux/mtd/rawnand.h         | 24 ++++++++++++
 5 files changed, 157 insertions(+), 13 deletions(-)
drivers/mtd/nand/raw/internals.h +2 -1
index fbf6ca015cd7..4fcb9f87caaf 100644
@@ -81,7 +81,8 @@ int nand_erase_nand(struct nand_chip *chip, struct erase_info *instr,
 		    int allowbbt);
 int onfi_fill_data_interface(struct nand_chip *chip,
 			     enum nand_data_interface_type type,
-			     int timing_mode);
+			     int timing_mode,
+			     enum non_onfi_spec_timing spec_timing);
 int nand_get_features(struct nand_chip *chip, int addr, u8 *subfeature_param);
 int nand_set_features(struct nand_chip *chip, int addr, u8 *subfeature_param);
 int nand_read_page_raw_notsupp(struct nand_chip *chip, u8 *buf,
drivers/mtd/nand/raw/nand_base.c +65 -8

114 lines not on this page · raw message

drivers/mtd/nand/raw/nand_ids.c +4 -0
index ea5a342cd91e..b1eb508a74e0 100644
@@ -56,6 +56,10 @@ struct nand_flash_dev nand_flash_ids[] = {
 		{ .id = {0xad, 0xde, 0x94, 0xda, 0x74, 0xc4} },
 		  SZ_8K, SZ_8K, SZ_2M, NAND_NEED_SCRAMBLING, 6, 640,
 		  NAND_ECC_INFO(40, SZ_1K), 4 },
+	{"TH58NVG2S3HBAI4 4G 3.3V 8-bit",
+		{ .id = {0x98, 0xdc, 0x91, 0x15, 0x76} },
+		SZ_2K, SZ_512, SZ_128K, 0, 5, 128, NAND_ECC_INFO(8, SZ_512),
+		0, NON_ONFI_TIMING_1},
 
 	LEGACY_ID_NAND("NAND 4MiB 5V 8-bit",   0x6B, 4, SZ_8K, SP_OPTIONS),
 	LEGACY_ID_NAND("NAND 4MiB 3,3V 8-bit", 0xE3, 4, SZ_8K, SP_OPTIONS),
drivers/mtd/nand/raw/nand_timings.c +62 -4

86 lines not on this page · raw message

include/linux/mtd/rawnand.h +24 -0
index b7445a44a814..329eff0951ed 100644
@@ -961,6 +961,17 @@ struct nand_legacy {
 };
 
 /**
+ * enum non_onfi_spec_timing - Special timing that can be used for
+ * non ONFI NAND.
+ * @NON_ONFI_TIMING_NOT_USED:	No special timings
+ * @NON_ONFI_TIMING_1:		Special timing 1
+ */
+enum non_onfi_spec_timing {
+	NON_ONFI_TIMING_NOT_USED,
+	NON_ONFI_TIMING_1,
+};
+
+/**
  * struct nand_chip - NAND Private Flash Chip Data
  * @mtd:		MTD device registered to the MTD framework
  * @legacy:		All legacy fields/hooks. If you develop a new driver,
@@ -1001,6 +1012,10 @@ struct nand_legacy {
  *			      set to the actually used ONFI mode if the chip is
  *			      ONFI compliant or deduced from the datasheet if
  *			      the NAND chip is not ONFI compliant.
+ * @spec_timing:	      [INTERN] This field is set to choose the special
+ *			      non onfi timings. This is used if the chip is not
+ *			      ONFI compliant and the timings does not correspond
+ *			      to any of the ONFI modes.
  * @numchips:		[INTERN] number of physical chips
  * @chipsize:		[INTERN] the size of one chip for multichip arrays
  * @pagemask:		[INTERN] page number mask = number of (pages / chip) - 1
@@ -1065,6 +1080,7 @@ struct nand_chip {
 	uint16_t ecc_strength_ds;
 	uint16_t ecc_step_ds;
 	int onfi_timing_mode_default;
+	enum non_onfi_spec_timing spec_timing;
 	int badblockpos;
 	int badblockbits;
 
@@ -1202,6 +1218,13 @@ static inline void *nand_get_manufacturer_data(struct nand_chip *chip)
  * @onfi_timing_mode_default: the default ONFI timing mode entered after a NAND
  *			      reset. Should be deduced from timings described
  *			      in the datasheet.
+ * @spec_timing:	Alternative timing table to be used after a NAND reset.
+ *			This can be used for non ONFI NANDs that does not have
+ *			timings that correspond well to the ONFI timing modes.
+ *			This value references non_onfi_spec_sdr_timings[] in
+ *			nand_timings.c.
+ *			Should be deduced from timings described
+ *			in the datasheet.
  *
  */
 struct nand_flash_dev {
@@ -1224,6 +1247,7 @@ struct nand_flash_dev {
 		uint16_t step_ds;
 	} ecc;
 	int onfi_timing_mode_default;
+	enum non_onfi_spec_timing spec_timing;
 };
 
 int nand_create_bbt(struct nand_chip *chip);
Signature · 6 lines
2.11.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
maintainer
#1 lore raw

Hi Rickard,

+ boris

Rickard Andersson <[email protected]> wrote on Wed, 22 Apr 2020 14:18:00 +0200:

Quoted 9 lines

From: Rickard x Andersson <[email protected]>

The Kioxia/Toshiba TH58NVG2S3HBAI4 NAND memory is not a ONFI compliant memory. The timings of that memory are quite close to ONFI mode 4 but is breaking that spec.

This patch adds a special table with timings that can be used for non ONFI memories.

Quoted 6 lines

Erase block read speed is increased from 6739 KiB/s to 13260 KiB/s. Erase block write speed is increased from 3004 KiB/s to 3872 KiB/s.

Tested on IMX6ULL which has a NAND controller supporting EDO mode.

I am convinced about the idea of tweaking non-ONFI timings on a per-chip basis to enhance their throughput, but I think we should do this another way.

What we could have is a way, for NAND manufacturer drivers, to overload the timings. This way, Kioxia timings remain in the Toshiba driver.

I quickly prepared a small series [1], it is untested but it will hopefully help you adapt your patch. You just have to set the chip->init_data_interface() hook from the Toshiba driver at init time. This hook is supposed to update the whole data interface structure and also call chip->controller.ops() to verify it is supported by the controller.

[1] https://github.com/miquelraynal/linux/tree/perso/nand-next/timings

Thanks,
Miquèl

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

maintainer
#2 lore raw

Hi Rickard,

Miquel Raynal <[email protected]> wrote on Tue, 12 May 2020 21:09:33 +0200:

Quoted 30 lines

Hi Rickard,

+ boris

Rickard Andersson <[email protected]> wrote on Wed, 22 Apr 2020 14:18:00 +0200:

Quoted 9 lines

From: Rickard x Andersson <[email protected]>

The Kioxia/Toshiba TH58NVG2S3HBAI4 NAND memory is not a ONFI compliant memory. The timings of that memory are quite close to ONFI mode 4 but is breaking that spec.

This patch adds a special table with timings that can be used for non ONFI memories.

Quoted 6 lines

Erase block read speed is increased from 6739 KiB/s to 13260 KiB/s. Erase block write speed is increased from 3004 KiB/s to 3872 KiB/s.

Tested on IMX6ULL which has a NAND controller supporting EDO mode.

I am convinced about the idea of tweaking non-ONFI timings on a per-chip basis to enhance their throughput, but I think we should do this another way.

What we could have is a way, for NAND manufacturer drivers, to overload the timings. This way, Kioxia timings remain in the Toshiba driver.

Quoted 8 lines

I quickly prepared a small series [1], it is untested but it will hopefully help you adapt your patch. You just have to set the chip->init_data_interface() hook from the Toshiba driver at init time. This hook is supposed to update the whole data interface structure and also call chip->controller.ops() to verify it is supported by the controller.

[1] https://github.com/miquelraynal/linux/tree/perso/nand-next/timings

Boris commented on Github, so I updated the code and pushed -f

Thanks,
Miquèl

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

#3 lore raw

Hi,

Thanks for the feedback. I have now created a new patchset on top of your patches. Will send it very soon.

BR
Rickard Andersson
________________________________________
Från: Miquel Raynal <[email protected]>
Skickat: den 13 maj 2020 10:48
Till: Rickard X Andersson
Kopia: [email protected]; [email protected]; [email protected]; [email protected]; Boris Brezillon Ämne: Re: [PATCH] mtd: rawnand: Non ONFI specialized timing support

Hi Rickard,

Miquel Raynal <[email protected]> wrote on Tue, 12 May 2020 21:09:33 +0200:

Quoted 30 lines

Hi Rickard,

+ boris

Rickard Andersson <[email protected]> wrote on Wed, 22 Apr 2020 14:18:00 +0200:

Quoted 9 lines

From: Rickard x Andersson <[email protected]>

The Kioxia/Toshiba TH58NVG2S3HBAI4 NAND memory is not a ONFI compliant memory. The timings of that memory are quite close to ONFI mode 4 but is breaking that spec.

This patch adds a special table with timings that can be used for non ONFI memories.

Quoted 6 lines

Erase block read speed is increased from 6739 KiB/s to 13260 KiB/s. Erase block write speed is increased from 3004 KiB/s to 3872 KiB/s.

Tested on IMX6ULL which has a NAND controller supporting EDO mode.

I am convinced about the idea of tweaking non-ONFI timings on a per-chip basis to enhance their throughput, but I think we should do this another way.

What we could have is a way, for NAND manufacturer drivers, to overload the timings. This way, Kioxia timings remain in the Toshiba driver.

Quoted 8 lines

I quickly prepared a small series [1], it is untested but it will hopefully help you adapt your patch. You just have to set the chip->init_data_interface() hook from the Toshiba driver at init time. This hook is supposed to update the whole data interface structure and also call chip->controller.ops() to verify it is supported by the controller.

[1] https://github.com/miquelraynal/linux/tree/perso/nand-next/timings

Boris commented on Github, so I updated the code and pushed -f

Thanks,
Miquèl

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