[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Prabhakar Kushwaha]

SPI-NOR framework currently supports-
 - (1-1-1, 1-1-2, 1-1-4) read protocols
 - read latency(dummy bytes) are hardcoded with the assumption
 that the flash would support it.
 - No support of mode bits.
 - No support of flash size above 128Mib

This patch set add support of 1-2-2, 1-4-4 read protocols. 
It ports Linux commits "mtd: spi-nor: add a stateless method to support
memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
and run time flash parameters discovery including dummy cycle and mode
cycle.

Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
provision for run-time LUTs creation.

Note: This patch-set is only **compliation** tested. Sending RFC to get
early feed-back on the approach.

Prabhakar Kushwaha (5):
  sf: Add support of 1-2-2, 1-4-4 IO READ protocols
  sf: add method to support memory size above 128Mib
  sf: parse Serial Flash Discoverable Parameters (SFDP) tables
  sf: fsl_qspi: Add support of fsl_qspi_set_mode
  sf: fsl_quadspi: Configue LUT based on padding information

 drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
 drivers/mtd/spi/spi_flash.c     | 574 +++++++++++++++++++++++++++++++++++++++-
 drivers/spi/fsl_qspi.c          |  85 +++++-
 include/spi_flash.h             |   2 +
 5 files changed, 875 insertions(+), 18 deletions(-)

-- 
2.7.4

[U-Boot] [RFC 1/5] sf: Add support of 1-2-2, 1-4-4 IO READ protocols

[Prabhakar Kushwaha]

IO READ protocols transfers both address and data on multiple
data bits. 1-2-2(DUAL IO), 1-4-4(QUAD IO) transfer address on 2
data bits or 4 bits per rising edge of SCK respectively.

This patch update spi_nor_flash_parameter->spi_nor_read_command
array based on DUAL or QUAD IO flag enabled in flash_info for a flash.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
---
 drivers/mtd/spi/spi_flash.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 51e28bf..4ff8d8b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1071,8 +1071,12 @@ int spi_flash_scan(struct spi_flash *flash)
 	flash->read_cmd = CMD_READ_ARRAY_FAST;
 	if (spi->mode & SPI_RX_SLOW)
 		flash->read_cmd = CMD_READ_ARRAY_SLOW;
+	else if (spi->mode & SPI_RX_QUAD && info->flags & RD_QUADIO)
+		flash->read_cmd = CMD_READ_QUAD_IO_FAST;
 	else if (spi->mode & SPI_RX_QUAD && info->flags & RD_QUAD)
 		flash->read_cmd = CMD_READ_QUAD_OUTPUT_FAST;
+	else if (spi->mode & SPI_RX_DUAL && info->flags & RD_DUALIO)
+		flash->read_cmd = CMD_READ_DUAL_IO_FAST;
 	else if (spi->mode & SPI_RX_DUAL && info->flags & RD_DUAL)
 		flash->read_cmd = CMD_READ_DUAL_OUTPUT_FAST;
 
-- 
2.7.4

[U-Boot] [RFC 2/5] sf: add method to support memory size above 128Mib

[Prabhakar Kushwaha]

This patch add support of memories with size above 128Mib. It has
been ported from Linux commit "mtd: spi-nor: add a
stateless method to support memory size above 128Mib".

It convert 3byte opcode into 4byte opcode based upon
OPCODES_4B or Spansion flash. Also the commands are malloc'ed
at run time based on 3byte or 4byte address opcode requirement.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
CC: Cyrille Pitchen <cyrille.pitchen@atmel.com>
CC: Marek Vasut <marek.vasut@gmail.com>
CC: Vignesh R <vigneshr@ti.com>
---
depends upon https://patchwork.ozlabs.org/patch/826919/

 drivers/mtd/spi/sf_internal.h |  28 ++++++++-
 drivers/mtd/spi/spi_flash.c   | 136 ++++++++++++++++++++++++++++++++++++------
 include/spi_flash.h           |   2 +
 3 files changed, 146 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 06dee0a..164b0ea 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -27,7 +27,8 @@ enum spi_nor_option_flags {
 };
 
 #define SPI_FLASH_3B_ADDR_LEN		3
-#define SPI_FLASH_CMD_LEN		(1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN		4
+#define SPI_FLASH_MAX_ADDR_WIDTH	4
 #define SPI_FLASH_16MB_BOUN		0x1000000
 
 /* CFI Manufacture ID's */
@@ -57,13 +58,30 @@ enum spi_nor_option_flags {
 #define CMD_READ_DUAL_IO_FAST		0xbb
 #define CMD_READ_QUAD_OUTPUT_FAST	0x6b
 #define CMD_READ_QUAD_IO_FAST		0xeb
+
+/* 4B READ commands */
+#define CMD_READ_ARRAY_SLOW_4B		0x13
+#define CMD_READ_ARRAY_FAST_4B		0x0c
+#define CMD_READ_DUAL_OUTPUT_FAST_4B	0x3c
+#define CMD_READ_DUAL_IO_FAST_4B	0xbc
+#define CMD_READ_QUAD_OUTPUT_FAST_4B	0x6c
+#define CMD_READ_QUAD_IO_FAST_4B	0xec
+
+/* 4B Write commands */
+#define CMD_PAGE_PROGRAM_4B		0x12
+
+/* 4B Erase commands */
+#define CMD_ERASE_4K_4B			0x21
+#define CMD_ERASE_CHIP_4B		0x5c
+#define CMD_ERASE_64K_4B		0xdc
+
 #define CMD_READ_ID			0x9f
 #define CMD_READ_STATUS			0x05
 #define CMD_READ_STATUS1		0x35
 #define CMD_READ_CONFIG			0x35
 #define CMD_FLAG_STATUS			0x70
-#define CMD_EN4B				0xB7
-#define CMD_EX4B				0xE9
+#define CMD_EN4B			0xB7
+#define CMD_EX4B			0xE9
 
 /* Bank addr access commands */
 #ifdef CONFIG_SPI_FLASH_BAR
@@ -133,6 +151,10 @@ struct spi_flash_info {
 #define RD_DUAL			BIT(5)	/* use Dual Read */
 #define RD_QUADIO		BIT(6)	/* use Quad IO Read */
 #define RD_DUALIO		BIT(7)	/* use Dual IO Read */
+#define OPCODES_4B		BIT(8)	/*
+					 * Use dedicated 4byte address op codes
+					 * to support memory size above 128Mib.
+					 */
 #define RD_FULL			(RD_QUAD | RD_DUAL | RD_QUADIO | RD_DUALIO)
 };
 
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 997e858..2e82a90 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -22,12 +22,28 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
 {
 	/* cmd[0] is actual command */
-	cmd[1] = addr >> 16;
-	cmd[2] = addr >> 8;
-	cmd[3] = addr >> 0;
+
+	switch (flash->addr_width) {
+	case SPI_FLASH_3B_ADDR_LEN:
+		cmd[1] = addr >> 16;
+		cmd[2] = addr >> 8;
+		cmd[3] = addr >> 0;
+		break;
+
+	case SPI_FLASH_4B_ADDR_LEN:
+		cmd[1] = addr >> 24;
+		cmd[2] = addr >> 16;
+		cmd[3] = addr >> 8;
+		cmd[4] = addr >> 0;
+		break;
+
+	default:
+		debug("SF: Wrong opcode size\n");
+		break;
+	}
 }
 
 static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -74,6 +90,64 @@ static int write_sr(struct spi_flash *flash, u8 ws)
 	return 0;
 }
 
+static u8 spi_flash_convert_opcode(u8 opcode, const u8 table[][2], size_t size)
+{
+	size_t i;
+
+	for (i = 0; i < size; i++)
+		if (table[i][0] == opcode)
+			return table[i][1];
+
+	/* No conversion found, keep input op code. */
+	return opcode;
+}
+
+static inline u8 spi_flash_convert_3to4_read(u8 opcode)
+{
+	static const u8 spi_flash_3to4_read[][2] = {
+		{ CMD_READ_ARRAY_SLOW,          CMD_READ_ARRAY_SLOW_4B },
+		{ CMD_READ_ARRAY_FAST,          CMD_READ_ARRAY_FAST_4B },
+		{ CMD_READ_DUAL_OUTPUT_FAST,    CMD_READ_DUAL_OUTPUT_FAST_4B },
+		{ CMD_READ_DUAL_IO_FAST,        CMD_READ_DUAL_IO_FAST_4B },
+		{ CMD_READ_QUAD_OUTPUT_FAST,    CMD_READ_QUAD_OUTPUT_FAST_4B },
+		{ CMD_READ_QUAD_IO_FAST,        CMD_READ_QUAD_IO_FAST_4B },
+
+	};
+
+	return spi_flash_convert_opcode(opcode, spi_flash_3to4_read,
+				      ARRAY_SIZE(spi_flash_3to4_read));
+}
+
+static inline u8 spi_flash_convert_3to4_program(u8 opcode)
+{
+	static const u8 spi_flash_3to4_program[][2] = {
+		{ CMD_PAGE_PROGRAM, CMD_PAGE_PROGRAM_4B },
+	};
+
+	return spi_flash_convert_opcode(opcode, spi_flash_3to4_program,
+				      ARRAY_SIZE(spi_flash_3to4_program));
+}
+
+static inline u8 spi_flash_convert_3to4_erase(u8 opcode)
+{
+	static const u8 spi_flash_3to4_erase[][2] = {
+		{ CMD_ERASE_4K,	   CMD_ERASE_4K_4B },
+		{ CMD_ERASE_CHIP,  CMD_ERASE_CHIP_4B },
+		{ CMD_ERASE_64K,   CMD_ERASE_64K_4B },
+	};
+
+	return spi_flash_convert_opcode(opcode, spi_flash_3to4_erase,
+				      ARRAY_SIZE(spi_flash_3to4_erase));
+}
+
+static void spi_flash_set_4byte_opcodes(struct spi_flash *flash,
+					const struct spi_flash_info *info)
+{
+	flash->read_cmd = spi_flash_convert_3to4_read(flash->read_cmd);
+	flash->write_cmd = spi_flash_convert_3to4_program(flash->write_cmd);
+	flash->erase_cmd = spi_flash_convert_3to4_erase(flash->erase_cmd);
+}
+
 #if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
 static int read_cr(struct spi_flash *flash, u8 *rc)
 {
@@ -364,7 +438,7 @@ int spi_flash_write_common(struct spi_flash *flash, const u8 *cmd,
 int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
 {
 	u32 erase_size, erase_addr;
-	u8 cmd[SPI_FLASH_CMD_LEN];
+	u8 *cmd, cmdsz;
 	int ret = -1;
 
 	erase_size = flash->erase_size;
@@ -381,6 +455,13 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
 		}
 	}
 
+	cmdsz = 1 + flash->addr_width;
+	cmd = calloc(1, cmdsz);
+	if (!cmd) {
+		debug("SF: Failed to allocate cmd\n");
+		return -ENOMEM;
+	}
+
 	cmd[0] = flash->erase_cmd;
 	while (len) {
 		erase_addr = offset;
@@ -394,12 +475,12 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
 		if (ret < 0)
 			return ret;
 #endif
-		spi_flash_addr(erase_addr, cmd);
+		spi_flash_addr(flash, erase_addr, cmd);
 
 		debug("SF: erase %2x %2x %2x %2x (%x)\n", cmd[0], cmd[1],
 		      cmd[2], cmd[3], erase_addr);
 
-		ret = spi_flash_write_common(flash, cmd, sizeof(cmd), NULL, 0);
+		ret = spi_flash_write_common(flash, cmd, cmdsz, NULL, 0);
 		if (ret < 0) {
 			debug("SF: erase failed\n");
 			break;
@@ -423,7 +504,7 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
 	unsigned long byte_addr, page_size;
 	u32 write_addr;
 	size_t chunk_len, actual;
-	u8 cmd[SPI_FLASH_CMD_LEN];
+	u8 *cmd, cmdsz;
 	int ret = -1;
 
 	page_size = flash->page_size;
@@ -436,6 +517,13 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
 		}
 	}
 
+	cmdsz = 1 + flash->addr_width;
+	cmd = calloc(1, cmdsz);
+	if (!cmd) {
+		debug("SF: Failed to allocate cmd\n");
+		return -ENOMEM;
+	}
+
 	cmd[0] = flash->write_cmd;
 	for (actual = 0; actual < len; actual += chunk_len) {
 		write_addr = offset;
@@ -456,13 +544,13 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 offset,
 			chunk_len = min(chunk_len,
 					(size_t)spi->max_write_size);
 
-		spi_flash_addr(write_addr, cmd);
+		spi_flash_addr(flash, write_addr, cmd);
 
 		debug("SF: 0x%p => cmd = { 0x%02x 0x%02x%02x%02x } chunk_len = %zu\n",
 		      buf + actual, cmd[0], cmd[1], cmd[2], cmd[3], chunk_len);
 
-		ret = spi_flash_write_common(flash, cmd, sizeof(cmd),
-					buf + actual, chunk_len);
+		ret = spi_flash_write_common(flash, cmd, cmdsz,
+					     buf + actual, chunk_len);
 		if (ret < 0) {
 			debug("SF: write failed\n");
 			break;
@@ -537,7 +625,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
 		return 0;
 	}
 
-	cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
+	cmdsz = 1 + flash->addr_width + flash->dummy_byte;
 	cmd = calloc(1, cmdsz);
 	if (!cmd) {
 		debug("SF: Failed to allocate cmd\n");
@@ -565,7 +653,7 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 offset,
 		else
 			read_len = remain_len;
 
-		spi_flash_addr(read_addr, cmd);
+		spi_flash_addr(flash, read_addr, cmd);
 
 		ret = spi_flash_read_common(flash, cmd, cmdsz, data, read_len);
 		if (ret < 0) {
@@ -1172,10 +1260,6 @@ int spi_flash_scan(struct spi_flash *flash)
 		flash->flags |= SNOR_F_USE_FSR;
 #endif
 
-	/* disable 4-byte addressing if the device exceeds 16MiB */
-	if (flash->size > SPI_FLASH_16MB_BOUN)
-		set_4byte(flash, info, 0);
-
 	/* Configure the BAR - discover bank cmds and read current bank */
 #ifdef CONFIG_SPI_FLASH_BAR
 	ret = read_bar(flash, info);
@@ -1211,5 +1295,23 @@ int spi_flash_scan(struct spi_flash *flash)
 	}
 #endif
 
+	if (flash->size > SPI_FLASH_16MB_BOUN) {
+		/* enable 4-byte addressing if the device exceeds 16MiB */
+		flash->addr_width = SPI_FLASH_4B_ADDR_LEN;
+		if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SPANSION ||
+		    info->flags & OPCODES_4B)
+			spi_flash_set_4byte_opcodes(flash, info);
+		else
+			set_4byte(flash, info, 1);
+	} else {
+		flash->addr_width = SPI_FLASH_3B_ADDR_LEN;
+	}
+
+	if (flash->addr_width > SPI_FLASH_MAX_ADDR_WIDTH) {
+		dev_err(dev, "address width is too large: %u\n",
+			flash->addr_width);
+		return -EINVAL;
+	}
+
 	return 0;
 }
diff --git a/include/spi_flash.h b/include/spi_flash.h
index be2fe3f..5a91671 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -48,6 +48,7 @@ struct spi_slave;
  * @read_cmd:		Read cmd - Array Fast, Extn read and quad read.
  * @write_cmd:		Write cmd - page and quad program.
  * @dummy_byte:		Dummy cycles for read operation.
+ * @addr_width:		number of address bytes
  * @memory_map:		Address of read-only SPI flash access
  * @flash_lock:		lock a region of the SPI Flash
  * @flash_unlock:	unlock a region of the SPI Flash
@@ -84,6 +85,7 @@ struct spi_flash {
 	u8 write_cmd;
 	u8 dummy_byte;
 
+	u8 addr_width;
 	void *memory_map;
 
 	int (*flash_lock)(struct spi_flash *flash, u32 ofs, size_t len);
-- 
2.7.4

[U-Boot] [RFC 3/5] sf: parse Serial Flash Discoverable Parameters (SFDP) tables

[Prabhakar Kushwaha]

This patch adds support to the JESD216 rev B standard and parses the
SFDP tables to dynamically initialize the 'struct spi_nor_flash_parameter'.

It has been ported from Linux commit "mtd: spi-nor: parse Serial Flash
Discoverable Parameters (SFDP) tables". It Also ports all modifications
done on top of the mentioned commit.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
CC: Cyrille Pitchen <cyrille.pitchen@atmel.com>
CC: Marek Vasut <marek.vasut@gmail.com>
---
 drivers/mtd/spi/sf_internal.h | 204 ++++++++++++++++++++++
 drivers/mtd/spi/spi_flash.c   | 389 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 593 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 164b0ea..73fe207 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -12,6 +12,7 @@
 
 #include <linux/types.h>
 #include <linux/compiler.h>
+#include <linux/sizes.h>
 
 /* Dual SPI flash memories - see SPI_COMM_DUAL_... */
 enum spi_dual_flash {
@@ -82,6 +83,7 @@ enum spi_nor_option_flags {
 #define CMD_FLAG_STATUS			0x70
 #define CMD_EN4B			0xB7
 #define CMD_EX4B			0xE9
+#define CMD_READ_SFDP			0x5a
 
 /* Bank addr access commands */
 #ifdef CONFIG_SPI_FLASH_BAR
@@ -155,9 +157,211 @@ struct spi_flash_info {
 					 * Use dedicated 4byte address op codes
 					 * to support memory size above 128Mib.
 					 */
+#define FLASH_SFDP		BIT(9)	 /* Parse SFDP tables */
 #define RD_FULL			(RD_QUAD | RD_DUAL | RD_QUADIO | RD_DUALIO)
 };
 
+struct sfdp_parameter_header {
+	u8		id_lsb;
+	u8		minor;
+	u8		major;
+	u8		length; /* in double words */
+	u8		parameter_table_pointer[3]; /* byte address */
+	u8		id_msb;
+};
+
+#define SFDP_PARAM_HEADER_ID(p)	(((p)->id_msb << 8) | (p)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(p) \
+	(((p)->parameter_table_pointer[2] << 16) | \
+	 ((p)->parameter_table_pointer[1] <<  8) | \
+	 ((p)->parameter_table_pointer[0] <<  0))
+
+#define SFDP_BFPT_ID		0xff00	/* Basic Flash Parameter Table */
+#define SFDP_SECTOR_MAP_ID	0xff81	/* Sector Map Table */
+
+#define SFDP_SIGNATURE		0x50444653U
+#define SFDP_JESD216_MAJOR	1
+#define SFDP_JESD216_MINOR	0
+#define SFDP_JESD216A_MINOR	5
+#define SFDP_JESD216B_MINOR	6
+
+struct sfdp_header {
+	u32		signature; /* Ox50444653U <=> "SFDP" */
+	u8		minor;
+	u8		major;
+	u8		nph; /* 0-base number of parameter headers */
+	u8		unused;
+
+	/* Basic Flash Parameter Table. */
+	struct sfdp_parameter_header	bfpt_header;
+};
+
+/* Basic Flash Parameter Table */
+
+/*
+ * JESD216 rev B defines a Basic Flash Parameter Table of 16 DWORDs.
+ * They are indexed from 1 but C arrays are indexed from 0.
+ */
+#define BFPT_DWORD(i)		((i) - 1)
+#define BFPT_DWORD_MAX		16
+
+/* The first version of JESB216 defined only 9 DWORDs. */
+#define BFPT_DWORD_MAX_JESD216			9
+
+/* 1st DWORD. */
+#define BFPT_DWORD1_FAST_READ_1_1_2		BIT(16)
+#define BFPT_DWORD1_ADDRESS_BYTES_MASK		GENMASK(18, 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_ONLY	(0x0UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_3_OR_4	(0x1UL << 17)
+#define BFPT_DWORD1_ADDRESS_BYTES_4_ONLY	(0x2UL << 17)
+#define BFPT_DWORD1_DTR				BIT(19)
+#define BFPT_DWORD1_FAST_READ_1_2_2		BIT(20)
+#define BFPT_DWORD1_FAST_READ_1_4_4		BIT(21)
+#define BFPT_DWORD1_FAST_READ_1_1_4		BIT(22)
+
+/* 5th DWORD. */
+#define BFPT_DWORD5_FAST_READ_2_2_2		BIT(0)
+#define BFPT_DWORD5_FAST_READ_4_4_4		BIT(4)
+
+/* 11th DWORD. */
+#define BFPT_DWORD11_PAGE_SIZE_SHIFT		4
+#define BFPT_DWORD11_PAGE_SIZE_MASK		GENMASK(7, 4)
+
+/* 15th DWORD. */
+
+/*
+ * (from JESD216 rev B)
+ * Quad Enable Requirements (QER):
+ * - 000b: Device does not have a QE bit. Device detects 1-1-4 and 1-4-4
+ *         reads based on instruction. DQ3/HOLD# functions are hold during
+ *         instruction phase.
+ * - 001b: QE is bit 1 of status register 2. It is set via Write Status with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ *         Writing only one byte to the status register has the side-effect of
+ *         clearing status register 2, including the QE bit. The 100b code is
+ *         used if writing one byte to the status register does not modify
+ *         status register 2.
+ * - 010b: QE is bit 6 of status register 1. It is set via Write Status with
+ *         one data byte where bit 6 is one.
+ *         [...]
+ * - 011b: QE is bit 7 of status register 2. It is set via Write status
+ *         register 2 instruction 3Eh with one data byte where bit 7 is one.
+ *         [...]
+ *         The status register 2 is read using instruction 3Fh.
+ * - 100b: QE is bit 1 of status register 2. It is set via Write Status with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ *         In contrast to the 001b code, writing one byte to the status
+ *         register does not modify status register 2.
+ * - 101b: QE is bit 1 of status register 2. Status register 1 is read using
+ *         Read Status instruction 05h. Status register2 is read using
+ *         instruction 35h. QE is set via Writ Status instruction 01h with
+ *         two data bytes where bit 1 of the second byte is one.
+ *         [...]
+ */
+#define BFPT_DWORD15_QER_MASK			GENMASK(22, 20)
+#define BFPT_DWORD15_QER_NONE			(0x0UL << 20) /* Micron */
+#define BFPT_DWORD15_QER_SR2_BIT1_BUGGY		(0x1UL << 20)
+#define BFPT_DWORD15_QER_SR1_BIT6		(0x2UL << 20) /* Macronix */
+#define BFPT_DWORD15_QER_SR2_BIT7		(0x3UL << 20)
+#define BFPT_DWORD15_QER_SR2_BIT1_NO_RD		(0x4UL << 20)
+#define BFPT_DWORD15_QER_SR2_BIT1		(0x5UL << 20) /* Spansion */
+
+struct sfdp_bfpt {
+	u32	dwords[BFPT_DWORD_MAX];
+};
+
+/* Fast Read settings. */
+
+struct sfdp_bfpt_read {
+	/*
+	 * The <supported_bit> bit in <supported_dword> BFPT DWORD tells us
+	 * whether the Fast Read x-y-z command is supported.
+	 */
+	u32			supported_dword;
+	u32			supported_bit;
+
+	/*
+	 * The half-word at offset <setting_shift> in <setting_dword> BFPT DWORD
+	 * encodes the op code, the number of mode clocks and the number of wait
+	 * states to be used by Fast Read x-y-z command.
+	 */
+	u32			settings_dword;
+	u32			settings_shift;
+
+	/* The SPI Read x-y-z command. */
+	u8			read_cmd;
+
+};
+
+static const struct sfdp_bfpt_read sfdp_bfpt_reads[] = {
+	/* Fast Read 1-1-2 */
+	{
+		BFPT_DWORD(1), BIT(16),	/* Supported bit */
+		BFPT_DWORD(4), 0,	/* Settings */
+		CMD_READ_DUAL_OUTPUT_FAST,
+	},
+
+	/* Fast Read 1-2-2 */
+	{
+		BFPT_DWORD(1), BIT(20),	/* Supported bit */
+		BFPT_DWORD(4), 16,	/* Settings */
+		CMD_READ_DUAL_IO_FAST,
+	},
+
+	/* Fast Read 2-2-2 */
+	{
+		BFPT_DWORD(5),  BIT(0),	/* Supported bit */
+		BFPT_DWORD(6), 16,	/* Settings */
+		0xFF,			/* Not supported cmd */
+	},
+
+	/* Fast Read 1-1-4 */
+	{
+		BFPT_DWORD(1), BIT(22),	/* Supported bit */
+		BFPT_DWORD(3), 16,	/* Settings */
+		CMD_READ_QUAD_OUTPUT_FAST,
+	},
+
+	/* Fast Read 1-4-4 */
+	{
+		BFPT_DWORD(1), BIT(21),	/* Supported bit */
+		BFPT_DWORD(3), 0,	/* Settings */
+		CMD_READ_QUAD_IO_FAST,
+	},
+
+	/* Fast Read 4-4-4 */
+	{
+		BFPT_DWORD(5), BIT(4),	/* Supported bit */
+		BFPT_DWORD(7), 16,	/* Settings */
+		0xFF,			/* Not supported cmd */
+	},
+};
+
+struct sfdp_bfpt_erase {
+	/*
+	 * The half-word at offset <shift> in DWORD <dwoard> encodes the
+	 * op code and erase sector size to be used by Sector Erase commands.
+	 */
+	u32			dword;
+	u32			shift;
+};
+
+static const struct sfdp_bfpt_erase sfdp_bfpt_erases[] = {
+	/* Erase Type 1 in DWORD8 bits[15:0] */
+	{BFPT_DWORD(8), 0},
+
+	/* Erase Type 2 in DWORD8 bits[31:16] */
+	{BFPT_DWORD(8), 16},
+
+	/* Erase Type 3 in DWORD9 bits[15:0] */
+	{BFPT_DWORD(9), 0},
+
+	/* Erase Type 4 in DWORD9 bits[31:16] */
+	{BFPT_DWORD(9), 16},
+};
+
 extern const struct spi_flash_info spi_flash_ids[];
 
 /* Send a single-byte command to the device and read the response */
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 2e82a90..39688cd 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1107,6 +1107,391 @@ int spi_flash_decode_fdt(struct spi_flash *flash)
 }
 #endif /* CONFIG_IS_ENABLED(OF_CONTROL) */
 
+/*
+ * Serial Flash Discoverable Parameters (SFDP) parsing.
+ */
+
+/**
+ * spi_flash_read_sfdp() - read Serial Flash Discoverable Parameters.
+ * @flash:	pointer to a 'struct spi_flash'
+ * @addr:	offset in the SFDP area to start reading data from
+ * @len:	number of bytes to read
+ * @buf:	buffer where the SFDP data are copied into (dma-safe memory)
+ *
+ * Whatever the actual numbers of bytes for address and dummy cycles are
+ * for (Fast) Read commands, the Read SFDP (5Ah) instruction is always
+ * followed by a 3-byte address and 8 dummy clock cycles.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_flash_read_sfdp(struct spi_flash *flash, u32 addr,
+			       size_t len, void *buf)
+{
+	u8 addr_width, read_cmd, dummy_byte;
+	int ret;
+
+	ret = spi_claim_bus(flash->spi);
+	if (ret) {
+		debug("SF: Unable to claim SPI bus\n");
+		return ret;
+	}
+
+	read_cmd = flash->read_cmd;
+	addr_width = flash->addr_width;
+	dummy_byte = flash->dummy_byte;
+
+	flash->read_cmd = CMD_READ_SFDP;
+	flash->addr_width = 3;
+	flash->dummy_byte = 2;
+
+	while (len) {
+		ret = spi_flash_cmd_read_ops(flash, addr, len, (u8 *)buf);
+		if (!ret || ret > len) {
+			ret = -EIO;
+			goto read_err;
+		}
+		if (ret < 0)
+			goto read_err;
+
+		buf += ret;
+		addr += ret;
+		len -= ret;
+	}
+	ret = 0;
+
+read_err:
+	flash->read_cmd = read_cmd;
+	flash->addr_width = addr_width;
+	flash->dummy_byte = dummy_byte;
+
+	spi_release_bus(flash->spi);
+	return ret;
+}
+
+/**
+ * spi_flash_read_sfdp_dma_unsafe() - read Serial Flash Discoverable Parameters.
+ * @flash:	pointer to a 'struct spi_flash'
+ * @addr:	offset in the SFDP area to start reading data from
+ * @len:	number of bytes to read
+ * @buf:	buffer where the SFDP data are copied into
+ *
+ * Wrap spi_flash_read_sfdp() using a kmalloc'ed bounce buffer as @buf is now
+ * not guaranteed to be dma-safe.
+ *
+ * Return: -ENOMEM if kmalloc() fails, the return code of spi_flash_read_sfdp()
+ *          otherwise.
+ */
+static int spi_flash_read_sfdp_dma_unsafe(struct spi_flash *flash, u32 addr,
+					  size_t len, void *buf)
+{
+	void *dma_safe_buf;
+	int ret;
+
+	dma_safe_buf = kmalloc(len, GFP_KERNEL);
+	if (!dma_safe_buf)
+		return -ENOMEM;
+
+	ret = spi_flash_read_sfdp(flash, addr, len, dma_safe_buf);
+	memcpy(buf, dma_safe_buf, len);
+	kfree(dma_safe_buf);
+
+	return ret;
+}
+
+/**
+ * spi_flash_parse_bfpt() - read and parse the Basic Flash Parameter Table.
+ * @flash:		pointer to a 'struct spi_flash'
+ * @info:		pointer to a 'struct spi_flash_info'
+ * @bfpt_header:	pointer to the 'struct sfdp_parameter_header' describing
+ *			the Basic Flash Parameter Table length and version
+ *
+ * The Basic Flash Parameter Table is the main and only mandatory table as
+ * defined by the SFDP (JESD216) specification.
+ * It provides us with the total size (memory density) of the data array and
+ * the number of address bytes for Fast Read, Page Program and Sector Erase
+ * commands.
+ * For Fast READ commands, it also gives the number of mode clock cycles and
+ * wait states (regrouped in the number of dummy clock cycles) for each
+ * supported instruction op code.
+ * For Page Program, the page size is now available since JESD216 rev A, however
+ * the supported instruction op codes are still not provided.
+ * For Sector Erase commands, this table stores the supported instruction op
+ * codes and the associated sector sizes.
+ * Finally, the Quad Enable Requirements (QER) are also available since JESD216
+ * rev A. The QER bits encode the manufacturer dependent procedure to be
+ * executed to set the Quad Enable (QE) bit in some internal register of the
+ * Quad SPI memory. Indeed the QE bit, when it exists, must be set before
+ * sending any Quad SPI command to the memory. Actually, setting the QE bit
+ * tells the memory to reassign its WP# and HOLD#/RESET# pins to functions IO2
+ * and IO3 hence enabling 4 (Quad) I/O lines.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_flash_parse_bfpt(struct spi_flash *flash,
+				const struct sfdp_parameter_header *bfpt_header)
+{
+	struct sfdp_bfpt bfpt;
+	size_t len;
+	int i, err;
+	u32 addr;
+	u16 half;
+
+	/* JESD216 Basic Flash Parameter Table length is at least 9 DWORDs. */
+	if (bfpt_header->length < BFPT_DWORD_MAX_JESD216)
+		return -EINVAL;
+
+	/* Read the Basic Flash Parameter Table. */
+	len = min_t(size_t, sizeof(bfpt),
+		    bfpt_header->length * sizeof(u32));
+	addr = SFDP_PARAM_HEADER_PTP(bfpt_header);
+	memset(&bfpt, 0, sizeof(bfpt));
+	err = spi_flash_read_sfdp_dma_unsafe(flash,  addr, len, &bfpt);
+	if (err < 0)
+		return err;
+
+	/* Fix endianness of the BFPT DWORDs. */
+	for (i = 0; i < BFPT_DWORD_MAX; i++)
+		bfpt.dwords[i] = le32_to_cpu(bfpt.dwords[i]);
+
+	/* Number of address bytes. */
+	switch (bfpt.dwords[BFPT_DWORD(1)] & BFPT_DWORD1_ADDRESS_BYTES_MASK) {
+	case BFPT_DWORD1_ADDRESS_BYTES_3_ONLY:
+		flash->addr_width = 3;
+		break;
+
+	case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY:
+		flash->addr_width = 4;
+		break;
+
+	default:
+		break;
+	}
+
+	/* Flash Memory Density (in bits). */
+	flash->size = bfpt.dwords[BFPT_DWORD(2)];
+	if (flash->size & BIT(31)) {
+		flash->size &= ~BIT(31);
+
+		/*
+		 * Prevent overflows on params->size. Anyway, a NOR of 2^64
+		 * bits is unlikely to exist so this error probably means
+		 * the BFPT we are reading is corrupted/wrong.
+		 */
+		if (flash->size > 63)
+			return -EINVAL;
+
+		flash->size = 1ULL << flash->size;
+	} else {
+		flash->size++;
+	}
+	flash->size >>= 3; /* Convert to bytes. */
+	flash->size <<= flash->shift;
+
+	/* Fast Read settings. */
+	for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_reads); i++) {
+		const struct sfdp_bfpt_read *rd = &sfdp_bfpt_reads[i];
+		u32 mode_dummy_cycle;
+
+		if (!(bfpt.dwords[rd->supported_dword] & rd->supported_bit))
+			continue;
+
+		flash->read_cmd = rd->read_cmd;
+
+		half = bfpt.dwords[rd->settings_dword] >> rd->settings_shift;
+		mode_dummy_cycle = ((half >> 5) & 0x07) + ((half >> 0) & 0x1f);
+
+		switch (flash->read_cmd) {
+		case CMD_READ_QUAD_IO_FAST:
+			flash->dummy_byte = (mode_dummy_cycle * 4) / 8;
+			break;
+
+		case CMD_READ_DUAL_IO_FAST:
+			flash->dummy_byte = (mode_dummy_cycle * 2) / 8;
+			break;
+
+		default:
+			flash->dummy_byte = mode_dummy_cycle / 8;
+			break;
+		}
+	}
+
+	/* Sector Erase settings. */
+	for (i = 0; i < ARRAY_SIZE(sfdp_bfpt_erases); i++) {
+		const struct sfdp_bfpt_erase *er = &sfdp_bfpt_erases[i];
+		u32 erasesize;
+		u8 opcode;
+
+		half = bfpt.dwords[er->dword] >> er->shift;
+		erasesize = half & 0xff;
+
+		/* erasesize == 0 means this Erase Type is not supported. */
+		if (!erasesize)
+			continue;
+
+		erasesize = 1U << erasesize;
+		opcode = (half >> 8) & 0xff;
+#ifdef CONFIG_SPI_FLASH_USE_4K_SECTORS
+		if (erasesize == SZ_4K) {
+			flash->erase_cmd = opcode;
+			flash->erase_size <<= flash->shift;
+			break;
+		}
+#endif
+		if (!flash->erase_size || flash->erase_size < erasesize) {
+			flash->erase_cmd = opcode;
+			flash->erase_size = erasesize;
+		}
+	}
+
+	/* Stop here if not JESD216 rev A or later. */
+	if (bfpt_header->length < BFPT_DWORD_MAX)
+		return 0;
+
+	/* Page size: this field specifies 'N' so the page size = 2^N bytes. */
+	flash->page_size = bfpt.dwords[BFPT_DWORD(11)];
+	flash->page_size &= BFPT_DWORD11_PAGE_SIZE_MASK;
+	flash->page_size >>= BFPT_DWORD11_PAGE_SIZE_SHIFT;
+	flash->page_size = 1U << flash->page_size;
+	flash->page_size <<= flash->shift;
+
+	/* Quad Enable Requirements. */
+	switch (bfpt.dwords[BFPT_DWORD(15)] & BFPT_DWORD15_QER_MASK) {
+	case BFPT_DWORD15_QER_NONE:
+		break;
+
+	case BFPT_DWORD15_QER_SR2_BIT1_BUGGY:
+	case BFPT_DWORD15_QER_SR2_BIT1_NO_RD:
+		break;
+
+	case BFPT_DWORD15_QER_SR1_BIT6:
+#ifdef CONFIG_SPI_FLASH_MACRONIX
+		macronix_quad_enable(flash);
+#endif
+		break;
+
+	case BFPT_DWORD15_QER_SR2_BIT7:
+		break;
+
+	case BFPT_DWORD15_QER_SR2_BIT1:
+#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
+		spansion_quad_enable(flash);
+#endif
+		break;
+
+	default:
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/**
+ * spi_flash_parse_sfdp() - parse the Serial Flash Discoverable Parameters.
+ * @flash:		pointer to a 'struct spi_flash'
+ *
+ * The Serial Flash Discoverable Parameters are described by the JEDEC JESD216
+ * specification. This is a standard which tends to supported by almost all
+ * (Q)SPI memory manufacturers. Those hard-coded tables allow us to learn at
+ * runtime the main parameters needed to perform basic SPI flash operations such
+ * as Fast Read, Page Program or Sector Erase commands.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spi_flash_parse_sfdp(struct spi_flash *flash)
+{
+	const struct sfdp_parameter_header *param_header, *bfpt_header;
+	struct sfdp_parameter_header *param_headers = NULL;
+	struct sfdp_header header;
+	size_t psize;
+	int i, err;
+
+	/* Get the SFDP header. */
+	err = spi_flash_read_sfdp_dma_unsafe(flash, 0, sizeof(header), &header);
+	if (err < 0)
+		return err;
+
+	/* Check the SFDP header version. */
+	if (le32_to_cpu(header.signature) != SFDP_SIGNATURE ||
+	    header.major != SFDP_JESD216_MAJOR ||
+	    header.minor < SFDP_JESD216_MINOR)
+		return -EINVAL;
+
+	/*
+	 * Verify that the first and only mandatory parameter header is a
+	 * Basic Flash Parameter Table header as specified in JESD216.
+	 */
+	bfpt_header = &header.bfpt_header;
+	if (SFDP_PARAM_HEADER_ID(bfpt_header) != SFDP_BFPT_ID ||
+	    bfpt_header->major != SFDP_JESD216_MAJOR)
+		return -EINVAL;
+
+	/*
+	 * Allocate memory then read all parameter headers with a single
+	 * Read SFDP command. These parameter headers will actually be parsed
+	 * twice: a first time to get the latest revision of the basic flash
+	 * parameter table, then a second time to handle the supported optional
+	 * tables.
+	 * Hence we read the parameter headers once for all to reduce the
+	 * processing time. Also we use kmalloc() instead of devm_kmalloc()
+	 * because we don't need to keep these parameter headers: the allocated
+	 * memory is always released with kfree() before exiting this function.
+	 */
+	if (header.nph) {
+		psize = header.nph * sizeof(*param_headers);
+
+		param_headers = kmalloc(psize, GFP_KERNEL);
+		if (!param_headers)
+			return -ENOMEM;
+
+		err = spi_flash_read_sfdp(flash, sizeof(header),
+					  psize, param_headers);
+		if (err < 0) {
+			debug("SF: failed to read SFDP parameter headers\n");
+			goto exit;
+		}
+	}
+
+	/*
+	 * Check other parameter headers to get the latest revision of
+	 * the basic flash parameter table.
+	 */
+	for (i = 0; i < header.nph; i++) {
+		param_header = &param_headers[i];
+
+		if (SFDP_PARAM_HEADER_ID(param_header) == SFDP_BFPT_ID &&
+		    param_header->major == SFDP_JESD216_MAJOR &&
+		    (param_header->minor > bfpt_header->minor ||
+		     (param_header->minor == bfpt_header->minor &&
+		      param_header->length > bfpt_header->length)))
+			bfpt_header = param_header;
+	}
+
+	err = spi_flash_parse_bfpt(flash, bfpt_header);
+	if (err)
+		goto exit;
+
+	/* Parse other parameter headers. */
+	for (i = 0; i < header.nph; i++) {
+		param_header = &param_headers[i];
+
+		switch (SFDP_PARAM_HEADER_ID(param_header)) {
+		case SFDP_SECTOR_MAP_ID:
+			debug("non-uniform erase sector maps not supported\n");
+			break;
+
+		default:
+			break;
+		}
+
+		if (err)
+			goto exit;
+	}
+
+exit:
+	kfree(param_headers);
+	return err;
+}
+
 int spi_flash_scan(struct spi_flash *flash)
 {
 	struct spi_slave *spi = flash->spi;
@@ -1313,5 +1698,9 @@ int spi_flash_scan(struct spi_flash *flash)
 		return -EINVAL;
 	}
 
+	/* Override the parameters with data read from SFDP tables. */
+	if (info->flags & (FLASH_SFDP))
+		spi_flash_parse_sfdp(flash);
+
 	return 0;
 }
-- 
2.7.4

[U-Boot] [RFC 4/5] sf: fsl_qspi: Add support of fsl_qspi_set_mode

[Prabhakar Kushwaha]

SPI bus provide support dual and quad wire data transfers for tx and
rx. This information is parsed from device tree and passed to slave
device via set_mode of dm_spi_ops.

Implement set_mode i.e. fsl_qspi_set_mode to store mode information
in fsl_qspi_priv structure.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
---
 drivers/spi/fsl_qspi.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 0f3f7d9..7ec222a 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -120,6 +120,7 @@ struct fsl_qspi_platdata {
  * @cur_amba_base: Base address of QSPI memory mapping of current CS
  * @flash_num: Number of active slave devices
  * @num_chipselect: Number of QSPI chipselect signals
+ * @mode: I/O lines
  * @regs: Point to QSPI register structure for I/O access
  */
 struct fsl_qspi_priv {
@@ -133,6 +134,7 @@ struct fsl_qspi_priv {
 	u32 cur_amba_base;
 	u32 flash_num;
 	u32 num_chipselect;
+	u32 mode;
 	struct fsl_qspi_regs *regs;
 };
 
@@ -1212,7 +1214,33 @@ static int fsl_qspi_set_speed(struct udevice *bus, uint speed)
 
 static int fsl_qspi_set_mode(struct udevice *bus, uint mode)
 {
-	/* Nothing to do */
+	struct fsl_qspi_priv *priv = dev_get_priv(bus);
+
+	if (mode & SPI_RX_QUAD)
+		priv->mode |= SPI_RX_QUAD;
+	else if (mode & SPI_RX_DUAL)
+		priv->mode |= SPI_RX_DUAL;
+	else
+		priv->mode &= ~(SPI_RX_QUAD | SPI_RX_DUAL);
+
+	priv->mode &= ~(SPI_TX_QUAD | SPI_TX_DUAL);
+
+	debug("%s:  mode=%d rx: ", __func__, mode);
+
+	if (mode & SPI_RX_QUAD)
+		debug("quad, tx: ");
+	else if (mode & SPI_RX_DUAL)
+		debug("dual, tx: ");
+	else
+		debug("single, tx: ");
+
+	if (mode & SPI_TX_QUAD)
+		debug("quad\n");
+	else if (mode & SPI_TX_DUAL)
+		debug("dual\n");
+	else
+		debug("single\n");
+
 	return 0;
 }
 
-- 
2.7.4

[U-Boot] [RFC 5/5] sf: fsl_quadspi: Configue LUT based on padding information

[Prabhakar Kushwaha]

Padding or number of line required for instruction, address and data
is pre-defined as per the selected read commond.

Configure LUT based on the selected read command under flag
SPI_XFER_BEGIN.

Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
---
 drivers/spi/fsl_qspi.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 7ec222a..bdaec44 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -52,7 +52,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #define QSPI_CMD_PP		0x02	/* Page program (up to 256 bytes) */
 #define QSPI_CMD_RDSR		0x05	/* Read status register */
 #define QSPI_CMD_WREN		0x06	/* Write enable */
+#define QSPI_CMD_SLOW_READ	0x03	/* Read data bytes (low frequency) */
 #define QSPI_CMD_FAST_READ	0x0b	/* Read data bytes (high frequency) */
+#define QSPI_CMD_DUAL_OUTPUT_FAST_READ	0x3b
+#define QSPI_CMD_DUAL_IO_FAST_READ	0xbb
+#define QSPI_CMD_QUAD_OUTPUT_FAST_READ	0x6b
+#define QSPI_CMD_QUAD_IO_FAST_READ	0xeb
 #define QSPI_CMD_BE_4K		0x20    /* 4K erase */
 #define QSPI_CMD_CHIP_ERASE	0xc7	/* Erase whole flash chip */
 #define QSPI_CMD_SE		0xd8	/* Sector erase (usually 64KiB) */
@@ -71,7 +76,12 @@ DECLARE_GLOBAL_DATA_PTR;
 #define QSPI_CMD_WRAR		0x71	/* Write any device register */
 
 /* 4-byte address QSPI CMD - used on Spansion and some Macronix flashes */
-#define QSPI_CMD_FAST_READ_4B	0x0c    /* Read data bytes (high frequency) */
+#define QSPI_CMD_SLOW_READ_4B		0x13
+#define QSPI_CMD_FAST_READ_4B		0x0c
+#define QSPI_CMD_DUAL_OUTPUT_FAST_READ_4B	0x3c
+#define QSPI_CMD_DUAL_IO_FAST_READ_4B		0xbc
+#define QSPI_CMD_QUAD_OUTPUT_FAST_READ_4B	0x6c
+#define QSPI_CMD_QUAD_IO_FAST_READ_4B		0xec
 #define QSPI_CMD_PP_4B		0x12    /* Page program (up to 256 bytes) */
 #define QSPI_CMD_SE_4B		0xdc    /* Sector erase (usually 64KiB) */
 
@@ -762,10 +772,51 @@ int qspi_xfer(struct fsl_qspi_priv *priv, unsigned int bitlen,
 {
 	u32 bytes = DIV_ROUND_UP(bitlen, 8);
 	static u32 wr_sfaddr;
-	u32 txbuf;
+	u32 txbuf, mode = priv->mode;
 
 	WATCHDOG_RESET();
 
+	if (dout && (flags & SPI_XFER_BEGIN)) {
+		switch (*(u8 *)dout) {
+		case QSPI_CMD_SLOW_READ:
+		case QSPI_CMD_SLOW_READ_4B:
+		case QSPI_CMD_FAST_READ:
+		case QSPI_CMD_FAST_READ_4B:
+		case QSPI_CMD_PP:
+		case QSPI_CMD_PP_4B:
+			/* TODO: 1_1_1 Padding */
+			break;
+
+		case QSPI_CMD_DUAL_OUTPUT_FAST_READ:
+		case QSPI_CMD_DUAL_OUTPUT_FAST_READ_4B:
+			if (mode & SPI_RX_DUAL) {
+				/* TODO: 1_1_2 Padding */
+			}
+			break;
+
+		case QSPI_CMD_DUAL_IO_FAST_READ:
+		case QSPI_CMD_DUAL_IO_FAST_READ_4B:
+			if (mode & SPI_RX_DUAL) {
+				/* TODO: 1_2_2 Padding */
+			}
+			break;
+
+		case QSPI_CMD_QUAD_OUTPUT_FAST_READ:
+		case QSPI_CMD_QUAD_OUTPUT_FAST_READ_4B:
+			if (mode & SPI_RX_QUAD) {
+				/* TODO: 1_1_4 Padding */
+			}
+			break;
+
+		case QSPI_CMD_QUAD_IO_FAST_READ:
+		case QSPI_CMD_QUAD_IO_FAST_READ_4B:
+			if (mode & SPI_RX_QUAD) {
+				/* TODO: 1_4_4 Padding */
+			}
+			break;
+		}
+	}
+
 	if (dout) {
 		if (flags & SPI_XFER_BEGIN) {
 			priv->cur_seqid = *(u8 *)dout;
-- 
2.7.4

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Marek Vasut]

On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
> SPI-NOR framework currently supports-
>  - (1-1-1, 1-1-2, 1-1-4) read protocols
>  - read latency(dummy bytes) are hardcoded with the assumption
>  that the flash would support it.
>  - No support of mode bits.
>  - No support of flash size above 128Mib
> 
> This patch set add support of 1-2-2, 1-4-4 read protocols. 
> It ports Linux commits "mtd: spi-nor: add a stateless method to support
> memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
> Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
> and run time flash parameters discovery including dummy cycle and mode
> cycle.
> 
> Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
> provision for run-time LUTs creation.
> 
> Note: This patch-set is only **compliation** tested. Sending RFC to get
> early feed-back on the approach.
> 
> Prabhakar Kushwaha (5):
>   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>   sf: add method to support memory size above 128Mib
>   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>   sf: fsl_quadspi: Configue LUT based on padding information
> 
>  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>  drivers/mtd/spi/spi_flash.c     | 574 +++++++++++++++++++++++++++++++++++++++-
>  drivers/spi/fsl_qspi.c          |  85 +++++-
>  include/spi_flash.h             |   2 +
>  5 files changed, 875 insertions(+), 18 deletions(-)
> 

Could you rather port the entire SPI NOR framework from Linux 4.14 ?
That'd make more sense than porting bits and pieces on top of the
current crappy code IMO.

-- 
Best regards,
Marek Vasut

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Prabhakar Kushwaha]

Hi Marek,

> -----Original Message-----
> From: Marek Vasut [mailto:marek.vasut at gmail.com]
> Sent: Monday, December 11, 2017 3:04 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at lists.denx.de
> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
> <poonam.aggrwal@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>;
> cyrille.pitchen at atmel.com
> Subject: Re: [RFC 0/5] sf: Update spi-nor framework
> 
> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
> > SPI-NOR framework currently supports-
> >  - (1-1-1, 1-1-2, 1-1-4) read protocols
> >  - read latency(dummy bytes) are hardcoded with the assumption
> >  that the flash would support it.
> >  - No support of mode bits.
> >  - No support of flash size above 128Mib
> >
> > This patch set add support of 1-2-2, 1-4-4 read protocols.
> > It ports Linux commits "mtd: spi-nor: add a stateless method to support
> > memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
> > Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
> > and run time flash parameters discovery including dummy cycle and mode
> > cycle.
> >
> > Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
> > provision for run-time LUTs creation.
> >
> > Note: This patch-set is only **compliation** tested. Sending RFC to get
> > early feed-back on the approach.
> >
> > Prabhakar Kushwaha (5):
> >   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
> >   sf: add method to support memory size above 128Mib
> >   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
> >   sf: fsl_qspi: Add support of fsl_qspi_set_mode
> >   sf: fsl_quadspi: Configue LUT based on padding information
> >
> >  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
> >  drivers/mtd/spi/spi_flash.c     | 574
> +++++++++++++++++++++++++++++++++++++++-
> >  drivers/spi/fsl_qspi.c          |  85 +++++-
> >  include/spi_flash.h             |   2 +
> >  5 files changed, 875 insertions(+), 18 deletions(-)
> >
> 
> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
> That'd make more sense than porting bits and pieces on top of the
> current crappy code IMO.

I agree with you. Linux 4.14 SPI NOR framework should be ported.
I may not able to do this because of bandwidth and lack of expertise.  
I will request Jagan (custodian) to look into this.

This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.

For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
Please help to share your views.

For next version of this patch set, I will be working on testing  it to enable other flashes. 
It will also help Jagan during 4.14 porting.  
Jagan, your views?

--pk   

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Jagan Teki]

On Tue, Dec 12, 2017 at 11:44 AM, Prabhakar Kushwaha
<prabhakar.kushwaha@nxp.com> wrote:
> Hi Marek,
>
>> -----Original Message-----
>> From: Marek Vasut [mailto:marek.vasut at gmail.com]
>> Sent: Monday, December 11, 2017 3:04 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
>> <poonam.aggrwal@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>;
>> cyrille.pitchen at atmel.com
>> Subject: Re: [RFC 0/5] sf: Update spi-nor framework
>>
>> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
>> > SPI-NOR framework currently supports-
>> >  - (1-1-1, 1-1-2, 1-1-4) read protocols
>> >  - read latency(dummy bytes) are hardcoded with the assumption
>> >  that the flash would support it.
>> >  - No support of mode bits.
>> >  - No support of flash size above 128Mib
>> >
>> > This patch set add support of 1-2-2, 1-4-4 read protocols.
>> > It ports Linux commits "mtd: spi-nor: add a stateless method to support
>> > memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
>> > Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
>> > and run time flash parameters discovery including dummy cycle and mode
>> > cycle.
>> >
>> > Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
>> > provision for run-time LUTs creation.
>> >
>> > Note: This patch-set is only **compliation** tested. Sending RFC to get
>> > early feed-back on the approach.
>> >
>> > Prabhakar Kushwaha (5):
>> >   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>> >   sf: add method to support memory size above 128Mib
>> >   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>> >   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>> >   sf: fsl_quadspi: Configue LUT based on padding information
>> >
>> >  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>> >  drivers/mtd/spi/spi_flash.c     | 574
>> +++++++++++++++++++++++++++++++++++++++-
>> >  drivers/spi/fsl_qspi.c          |  85 +++++-
>> >  include/spi_flash.h             |   2 +
>> >  5 files changed, 875 insertions(+), 18 deletions(-)
>> >
>>
>> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
>> That'd make more sense than porting bits and pieces on top of the
>> current crappy code IMO.
>
> I agree with you. Linux 4.14 SPI NOR framework should be ported.
> I may not able to do this because of bandwidth and lack of expertise.
> I will request Jagan (custodian) to look into this.
>
> This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.
>
> For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
> Please help to share your views.
>
> For next version of this patch set, I will be working on testing  it to enable other flashes.
> It will also help Jagan during 4.14 porting.
> Jagan, your views?

direct-porting from Linux is not so optimal(not well suited for U-Boot
design) as I've tried before. We're working on the dm-driven spi-nor.
So I will continue to review your patches on current code and will see
how we can merge the same once dm-spi-nor available.

Jagan.

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Vignesh R]

Hi Jagan,

On Tuesday 12 December 2017 01:07 PM, Jagan Teki wrote:
[...]
>>>> Prabhakar Kushwaha (5):
>>>>   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>>>>   sf: add method to support memory size above 128Mib
>>>>   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>>>>   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>>>>   sf: fsl_quadspi: Configue LUT based on padding information
>>>>
>>>>  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>>>>  drivers/mtd/spi/spi_flash.c     | 574
>>> +++++++++++++++++++++++++++++++++++++++-
>>>>  drivers/spi/fsl_qspi.c          |  85 +++++-
>>>>  include/spi_flash.h             |   2 +
>>>>  5 files changed, 875 insertions(+), 18 deletions(-)
>>>>
>>>
>>> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
>>> That'd make more sense than porting bits and pieces on top of the
>>> current crappy code IMO.
>>
>> I agree with you. Linux 4.14 SPI NOR framework should be ported.
>> I may not able to do this because of bandwidth and lack of expertise.
>> I will request Jagan (custodian) to look into this.
>>
>> This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.
>>
>> For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
>> Please help to share your views.
>>
>> For next version of this patch set, I will be working on testing  it to enable other flashes.
>> It will also help Jagan during 4.14 porting.
>> Jagan, your views?
> 
> direct-porting from Linux is not so optimal(not well suited for U-Boot
> design) as I've tried before. We're working on the dm-driven spi-nor.
> So I will continue to review your patches on current code and will see
> how we can merge the same once dm-spi-nor available.

Many of the newer SPI NOR flashes such as MT35x do not support U-Boot's
legacy way of accessing >128Mb region.
Are you planning to submit dm-spi-nor anytime soon? If not, then IMO, at
least patch 2/5 is worth considering for now.



-- 
Regards
Vignesh

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Marek Vasut]

On 12/12/2017 08:37 AM, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 11:44 AM, Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com> wrote:
>> Hi Marek,
>>
>>> -----Original Message-----
>>> From: Marek Vasut [mailto:marek.vasut at gmail.com]
>>> Sent: Monday, December 11, 2017 3:04 PM
>>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>>> boot at lists.denx.de
>>> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
>>> <poonam.aggrwal@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>;
>>> cyrille.pitchen at atmel.com
>>> Subject: Re: [RFC 0/5] sf: Update spi-nor framework
>>>
>>> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
>>>> SPI-NOR framework currently supports-
>>>>  - (1-1-1, 1-1-2, 1-1-4) read protocols
>>>>  - read latency(dummy bytes) are hardcoded with the assumption
>>>>  that the flash would support it.
>>>>  - No support of mode bits.
>>>>  - No support of flash size above 128Mib
>>>>
>>>> This patch set add support of 1-2-2, 1-4-4 read protocols.
>>>> It ports Linux commits "mtd: spi-nor: add a stateless method to support
>>>> memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
>>>> Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
>>>> and run time flash parameters discovery including dummy cycle and mode
>>>> cycle.
>>>>
>>>> Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
>>>> provision for run-time LUTs creation.
>>>>
>>>> Note: This patch-set is only **compliation** tested. Sending RFC to get
>>>> early feed-back on the approach.
>>>>
>>>> Prabhakar Kushwaha (5):
>>>>   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>>>>   sf: add method to support memory size above 128Mib
>>>>   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>>>>   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>>>>   sf: fsl_quadspi: Configue LUT based on padding information
>>>>
>>>>  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>>>>  drivers/mtd/spi/spi_flash.c     | 574
>>> +++++++++++++++++++++++++++++++++++++++-
>>>>  drivers/spi/fsl_qspi.c          |  85 +++++-
>>>>  include/spi_flash.h             |   2 +
>>>>  5 files changed, 875 insertions(+), 18 deletions(-)
>>>>
>>>
>>> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
>>> That'd make more sense than porting bits and pieces on top of the
>>> current crappy code IMO.
>>
>> I agree with you. Linux 4.14 SPI NOR framework should be ported.
>> I may not able to do this because of bandwidth and lack of expertise.
>> I will request Jagan (custodian) to look into this.
>>
>> This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.
>>
>> For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
>> Please help to share your views.
>>
>> For next version of this patch set, I will be working on testing  it to enable other flashes.
>> It will also help Jagan during 4.14 porting.
>> Jagan, your views?
> 
> direct-porting from Linux is not so optimal(not well suited for U-Boot
> design) as I've tried before.

Care to elaborate on the technical problems ? I am also CCing the Linux
SPI NOR maintainers, since I believe the Linux SPI NOR framework is far
superior compared to the stuff that's now in U-Boot and sharing the code
as much as possible would only make sense rather than writing our own
barely-maintained and crappy implementation.

> We're working on the dm-driven spi-nor.
> So I will continue to review your patches on current code and will see
> how we can merge the same once dm-spi-nor available.
> 
> Jagan.
> 


-- 
Best regards,
Marek Vasut

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Jagan Teki]

On Tue, Dec 12, 2017 at 9:31 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On 12/12/2017 08:37 AM, Jagan Teki wrote:
>> On Tue, Dec 12, 2017 at 11:44 AM, Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com> wrote:
>>> Hi Marek,
>>>
>>>> -----Original Message-----
>>>> From: Marek Vasut [mailto:marek.vasut at gmail.com]
>>>> Sent: Monday, December 11, 2017 3:04 PM
>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>>>> boot at lists.denx.de
>>>> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
>>>> <poonam.aggrwal@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>;
>>>> cyrille.pitchen at atmel.com
>>>> Subject: Re: [RFC 0/5] sf: Update spi-nor framework
>>>>
>>>> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
>>>>> SPI-NOR framework currently supports-
>>>>>  - (1-1-1, 1-1-2, 1-1-4) read protocols
>>>>>  - read latency(dummy bytes) are hardcoded with the assumption
>>>>>  that the flash would support it.
>>>>>  - No support of mode bits.
>>>>>  - No support of flash size above 128Mib
>>>>>
>>>>> This patch set add support of 1-2-2, 1-4-4 read protocols.
>>>>> It ports Linux commits "mtd: spi-nor: add a stateless method to support
>>>>> memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
>>>>> Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
>>>>> and run time flash parameters discovery including dummy cycle and mode
>>>>> cycle.
>>>>>
>>>>> Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
>>>>> provision for run-time LUTs creation.
>>>>>
>>>>> Note: This patch-set is only **compliation** tested. Sending RFC to get
>>>>> early feed-back on the approach.
>>>>>
>>>>> Prabhakar Kushwaha (5):
>>>>>   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>>>>>   sf: add method to support memory size above 128Mib
>>>>>   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>>>>>   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>>>>>   sf: fsl_quadspi: Configue LUT based on padding information
>>>>>
>>>>>  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>>>>>  drivers/mtd/spi/spi_flash.c     | 574
>>>> +++++++++++++++++++++++++++++++++++++++-
>>>>>  drivers/spi/fsl_qspi.c          |  85 +++++-
>>>>>  include/spi_flash.h             |   2 +
>>>>>  5 files changed, 875 insertions(+), 18 deletions(-)
>>>>>
>>>>
>>>> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
>>>> That'd make more sense than porting bits and pieces on top of the
>>>> current crappy code IMO.
>>>
>>> I agree with you. Linux 4.14 SPI NOR framework should be ported.
>>> I may not able to do this because of bandwidth and lack of expertise.
>>> I will request Jagan (custodian) to look into this.
>>>
>>> This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.
>>>
>>> For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
>>> Please help to share your views.
>>>
>>> For next version of this patch set, I will be working on testing  it to enable other flashes.
>>> It will also help Jagan during 4.14 porting.
>>> Jagan, your views?
>>
>> direct-porting from Linux is not so optimal(not well suited for U-Boot
>> design) as I've tried before.
>
> Care to elaborate on the technical problems ? I am also CCing the Linux
> SPI NOR maintainers, since I believe the Linux SPI NOR framework is far
> superior compared to the stuff that's now in U-Boot and sharing the code
> as much as possible would only make sense rather than writing our own
> barely-maintained and crappy implementation.

Yes we would take reference of spi-nor core especially for flash
handling but designed in the U-Boot driver model. direct porting of
Linux spi-nor become another crappy. we have an expertise of how we do
it let's wait for the series to post it on mailing-list.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Marek Vasut]

On 12/12/2017 05:12 PM, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 9:31 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/12/2017 08:37 AM, Jagan Teki wrote:
>>> On Tue, Dec 12, 2017 at 11:44 AM, Prabhakar Kushwaha
>>> <prabhakar.kushwaha@nxp.com> wrote:
>>>> Hi Marek,
>>>>
>>>>> -----Original Message-----
>>>>> From: Marek Vasut [mailto:marek.vasut at gmail.com]
>>>>> Sent: Monday, December 11, 2017 3:04 PM
>>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>>>>> boot at lists.denx.de
>>>>> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
>>>>> <poonam.aggrwal@nxp.com>; Suresh Gupta <suresh.gupta@nxp.com>;
>>>>> cyrille.pitchen at atmel.com
>>>>> Subject: Re: [RFC 0/5] sf: Update spi-nor framework
>>>>>
>>>>> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote:
>>>>>> SPI-NOR framework currently supports-
>>>>>>  - (1-1-1, 1-1-2, 1-1-4) read protocols
>>>>>>  - read latency(dummy bytes) are hardcoded with the assumption
>>>>>>  that the flash would support it.
>>>>>>  - No support of mode bits.
>>>>>>  - No support of flash size above 128Mib
>>>>>>
>>>>>> This patch set add support of 1-2-2, 1-4-4 read protocols.
>>>>>> It ports Linux commits "mtd: spi-nor: add a stateless method to support
>>>>>> memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
>>>>>> Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
>>>>>> and run time flash parameters discovery including dummy cycle and mode
>>>>>> cycle.
>>>>>>
>>>>>> Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
>>>>>> provision for run-time LUTs creation.
>>>>>>
>>>>>> Note: This patch-set is only **compliation** tested. Sending RFC to get
>>>>>> early feed-back on the approach.
>>>>>>
>>>>>> Prabhakar Kushwaha (5):
>>>>>>   sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>>>>>>   sf: add method to support memory size above 128Mib
>>>>>>   sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>>>>>>   sf: fsl_qspi: Add support of fsl_qspi_set_mode
>>>>>>   sf: fsl_quadspi: Configue LUT based on padding information
>>>>>>
>>>>>>  drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>>>>>>  drivers/mtd/spi/spi_flash.c     | 574
>>>>> +++++++++++++++++++++++++++++++++++++++-
>>>>>>  drivers/spi/fsl_qspi.c          |  85 +++++-
>>>>>>  include/spi_flash.h             |   2 +
>>>>>>  5 files changed, 875 insertions(+), 18 deletions(-)
>>>>>>
>>>>>
>>>>> Could you rather port the entire SPI NOR framework from Linux 4.14 ?
>>>>> That'd make more sense than porting bits and pieces on top of the
>>>>> current crappy code IMO.
>>>>
>>>> I agree with you. Linux 4.14 SPI NOR framework should be ported.
>>>> I may not able to do this because of bandwidth and lack of expertise.
>>>> I will request Jagan (custodian) to look into this.
>>>>
>>>> This RFC patch-set can easily be applied to existing and  ported Linux SPI NOR framework when it gets available.
>>>>
>>>> For now, I think these patches(the next version) with the existing framework can be reviewed and accepted.
>>>> Please help to share your views.
>>>>
>>>> For next version of this patch set, I will be working on testing  it to enable other flashes.
>>>> It will also help Jagan during 4.14 porting.
>>>> Jagan, your views?
>>>
>>> direct-porting from Linux is not so optimal(not well suited for U-Boot
>>> design) as I've tried before.
>>
>> Care to elaborate on the technical problems ? I am also CCing the Linux
>> SPI NOR maintainers, since I believe the Linux SPI NOR framework is far
>> superior compared to the stuff that's now in U-Boot and sharing the code
>> as much as possible would only make sense rather than writing our own
>> barely-maintained and crappy implementation.
> 
> Yes we would take reference of spi-nor core especially for flash
> handling but designed in the U-Boot driver model.

The SPI NOR layer in Linux should fit on top of that quite easily.

> direct porting of
> Linux spi-nor become another crappy. we have an expertise of how we do
> it let's wait for the series to post it on mailing-list.

What's the technical argument here ?

-- 
Best regards,
Marek Vasut

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Yang, Wenyou]

Hi,

On this topic, Cyrille has a patches here, as a reference.

https://lists.denx.de/pipermail/u-boot/2017-July/299409.html

On 2017/12/11 13:57, Prabhakar Kushwaha wrote:
> SPI-NOR framework currently supports-
>   - (1-1-1, 1-1-2, 1-1-4) read protocols
>   - read latency(dummy bytes) are hardcoded with the assumption
>   that the flash would support it.
>   - No support of mode bits.
>   - No support of flash size above 128Mib
>
> This patch set add support of 1-2-2, 1-4-4 read protocols.
> It ports Linux commits "mtd: spi-nor: add a stateless method to support
> memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash
> Discoverable Parameters (SFDP) tables". It enables 4byte address opcode
> and run time flash parameters discovery including dummy cycle and mode
> cycle.
>
> Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and
> provision for run-time LUTs creation.
>
> Note: This patch-set is only **compliation** tested. Sending RFC to get
> early feed-back on the approach.
>
> Prabhakar Kushwaha (5):
>    sf: Add support of 1-2-2, 1-4-4 IO READ protocols
>    sf: add method to support memory size above 128Mib
>    sf: parse Serial Flash Discoverable Parameters (SFDP) tables
>    sf: fsl_qspi: Add support of fsl_qspi_set_mode
>    sf: fsl_quadspi: Configue LUT based on padding information
>
>   drivers/mtd/spi/sf_internal.h   | 230 +++++++++++++++-
>   drivers/mtd/spi/spi_flash.c     | 574 +++++++++++++++++++++++++++++++++++++++-
>   drivers/spi/fsl_qspi.c          |  85 +++++-
>   include/spi_flash.h             |   2 +
>   5 files changed, 875 insertions(+), 18 deletions(-)
>

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Prabhakar Kushwaha]

Thanks Wenyou for the references.

I will check them while porting my patch-set to u-boot-spi.git. 

> -----Original Message-----
> From: Yang, Wenyou [mailto:Wenyou.Yang at Microchip.com]
> Sent: Thursday, January 04, 2018 7:28 AM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> boot at lists.denx.de
> Cc: Suresh Gupta <suresh.gupta@nxp.com>; cyrille.pitchen at atmel.com
> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
> 
> Hi,
> 
> On this topic, Cyrille has a patches here, as a reference.
> 
> https://lists.denx.de/pipermail/u-boot/2017-July/299409.html
>
> 

Any idea why these patches were not accepted?
Is it because of pending review/rework

--pk

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Jagan Teki]

On Thu, Jan 4, 2018 at 3:54 PM, Prabhakar Kushwaha
<prabhakar.kushwaha@nxp.com> wrote:
> Thanks Wenyou for the references.
>
> I will check them while porting my patch-set to u-boot-spi.git.
>
>> -----Original Message-----
>> From: Yang, Wenyou [mailto:Wenyou.Yang at Microchip.com]
>> Sent: Thursday, January 04, 2018 7:28 AM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>> boot at lists.denx.de
>> Cc: Suresh Gupta <suresh.gupta@nxp.com>; cyrille.pitchen at atmel.com
>> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
>>
>> Hi,
>>
>> On this topic, Cyrille has a patches here, as a reference.
>>
>> https://lists.denx.de/pipermail/u-boot/2017-July/299409.html
>>
>>
>
> Any idea why these patches were not accepted?
> Is it because of pending review/rework

reviewed and waiting for next version changes.

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Prabhakar Kushwaha]

Thanks Jagan 

Dear Yang Wenyou,

> -----Original Message-----
> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
> Sent: Thursday, January 04, 2018 3:57 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
> Cc: Yang, Wenyou <Wenyou.Yang@microchip.com>; u-boot at lists.denx.de;
> cyrille.pitchen at atmel.com; Suresh Gupta <suresh.gupta@nxp.com>
> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
> 
> On Thu, Jan 4, 2018 at 3:54 PM, Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com> wrote:
> > Thanks Wenyou for the references.
> >
> > I will check them while porting my patch-set to u-boot-spi.git.
> >
> >> -----Original Message-----
> >> From: Yang, Wenyou [mailto:Wenyou.Yang at Microchip.com]
> >> Sent: Thursday, January 04, 2018 7:28 AM
> >> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
> >> boot at lists.denx.de
> >> Cc: Suresh Gupta <suresh.gupta@nxp.com>; cyrille.pitchen at atmel.com
> >> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
> >>
> >> Hi,
> >>
> >> On this topic, Cyrille has a patches here, as a reference.
> >>
> >> https://lists.denx.de/pipermail/u-boot/2017-July/299409.html
> >>
> >>
> >
> > Any idea why these patches were not accepted?
> > Is it because of pending review/rework
> 

Are you planning to submit v4 patch in near future 
Or
may I pick few of your patches while porting to my patch-set on u-boot-spi.git.
Please note I am  also planning to add support of read_proto, write_proto similar to what supported in Linux. 

--pk 

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Yang, Wenyou]

On 2018/1/4 18:34, Prabhakar Kushwaha wrote:
> Thanks Jagan
>
> Dear Yang Wenyou,
>
>> -----Original Message-----
>> From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
>> Sent: Thursday, January 04, 2018 3:57 PM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
>> Cc: Yang, Wenyou <Wenyou.Yang@microchip.com>; u-boot at lists.denx.de;
>> cyrille.pitchen at atmel.com; Suresh Gupta <suresh.gupta@nxp.com>
>> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
>>
>> On Thu, Jan 4, 2018 at 3:54 PM, Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com> wrote:
>>> Thanks Wenyou for the references.
>>>
>>> I will check them while porting my patch-set to u-boot-spi.git.
>>>
>>>> -----Original Message-----
>>>> From: Yang, Wenyou [mailto:Wenyou.Yang at Microchip.com]
>>>> Sent: Thursday, January 04, 2018 7:28 AM
>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; u-
>>>> boot at lists.denx.de
>>>> Cc: Suresh Gupta <suresh.gupta@nxp.com>; cyrille.pitchen at atmel.com
>>>> Subject: Re: [U-Boot] [RFC 0/5] sf: Update spi-nor framework
>>>>
>>>> Hi,
>>>>
>>>> On this topic, Cyrille has a patches here, as a reference.
>>>>
>>>> https://lists.denx.de/pipermail/u-boot/2017-July/299409.html
>>>>
>>>>
>>> Any idea why these patches were not accepted?
>>> Is it because of pending review/rework
> Are you planning to submit v4 patch in near future
> Or
> may I pick few of your patches while porting to my patch-set on u-boot-spi.git.
> Please note I am  also planning to add support of read_proto, write_proto similar to what supported in Linux.
No, we don't have plan to submit v4 patch.
You are free to pick them.

Best Regards,
Wenyou Yang

>
> --pk
>
>

[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Goldschmidt Simon]

On Tuesday 12 December 2017 11:51, Vignesh R wrote:
> [...]
> Many of the newer SPI NOR flashes such as MT35x do not support U-Boot's
> legacy way of accessing >128Mb region.
> Are you planning to submit dm-spi-nor anytime soon? If not, then IMO, at
> least patch 2/5 is worth considering for now.

I haven't tested that patch, but I assume it uses 4-byte mode instead
of the bank register? That would certainly improve the situation in
my case, too, where the flash is in 4-byte mode after soft reset and
we would have to set it back to 3-byte mode.

(https://patchwork.ozlabs.org/patch/826919/)


Simon