mbox series

[v4,0/7] mtd: spi-nor: add xSPI Octal DTR support

Message ID 1590737775-4798-1-git-send-email-masonccyang@mxic.com.tw
Headers show
Series mtd: spi-nor: add xSPI Octal DTR support | expand

Message

Mason Yang May 29, 2020, 7:36 a.m. UTC
Hello,

JESD216C has defined specification for Octal 8S-8S-8S and 8D-8D-8D.
Based on JEDEC216C Basic Flash Parameter Table (BFPT) driver extract
DWORD-18: command and command extension type.
DWORD-20: Maximum operation speed of device in Octal mode.

xSPI profile 1.0 table:
DWORD-1: Read Fast command, the number of dummy cycles and address nbytes
	 for Read Status Register command.
DWORD-2: Read/Write volatile Register command for CFG Reg2.
DWORD-4 and DWORD-5: dummy cycles used for various frequencies based on
maximum speed of device from BFPT 20th DWORD.

Ccommand sequences to change to octal DTR mode:
The length of each command sequence is 8 per byte for single SPI mode and
patching driver to parse and execute these sequences for octal DTR mode.

By Vignesh's comments, this patches set is dependency on Pratyush's
[1][2][5][7][8] and [10][12].

Tested on Macronix's Zynq PicoZed board with Macronix's SPI controller
(spi-mxic.c) driver patched on mx25uw51245g Octal flash.

[1] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-2-p.yadav@ti.com/
[2] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-3-p.yadav@ti.com/
[5] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-6-p.yadav@ti.com/
[7] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-8-p.yadav@ti.com/
[8] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-9-p.yadav@ti.com/
[10] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-11-p.yadav@ti.com/
[12] https://patchwork.ozlabs.org/project/linux-mtd/patch/20200525091544.17270-13-p.yadav@ti.com/

Summary of change log
v4:
Removed Pratyush's patches set part.

v3:
Add support command sequences to change octal DTR mode and based on
part of Pratyush's patches set.

v2: 
Parse BFPT & xSPI table for Octal 8D-8D-8D mode parameters and enable Octal
mode in spi_nor_late_init_params().
Using Macros in spi_nor_spimem_read_data, spi_nor_spimem_write_data and
so on by Vignesh comments.

v1:
Without parsing BFPT & xSPI profile 1.0 table and enter Octal 8D-8D-8D
mode directly in spi_nor_fixups hooks.


thnaks for your time and review.
best regards,
Mason

Mason Yang (7):
  mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT
  mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
  mtd: spi-nor: sfdp: parse command sequences to change octal DTR mode
  mtd: spi-nor: core: add configuration register 2 read & write support
  mtd: spi-nor: core: execute command sequences to change octal DTR mode
  spi: mxic: patch for octal DTR mode support
  mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix
    mx25uw51245g

 drivers/mtd/spi-nor/core.c     | 151 ++++++++++++++++++++++++-
 drivers/mtd/spi-nor/core.h     |  41 +++++++
 drivers/mtd/spi-nor/macronix.c |  55 +++++++++
 drivers/mtd/spi-nor/sfdp.c     | 246 +++++++++++++++++++++++++++++++++++++++++
 drivers/mtd/spi-nor/sfdp.h     |   4 +
 drivers/spi/spi-mxic.c         |  98 ++++++++++------
 6 files changed, 562 insertions(+), 33 deletions(-)

Comments

Tudor Ambarus Oct. 28, 2020, 9:45 a.m. UTC | #1
Hi, Mason, YC Lin,

On 5/29/20 10:36 AM, Mason Yang wrote:
> A set of simple command sequences is provided which can be executed

> directly by the host controller to enable octal DTR mode.

> 

> Each command sequence is 8 per byte for single SPI mode.

> 

> Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>

> ---

>  drivers/mtd/spi-nor/core.h |  20 +++++++++

>  drivers/mtd/spi-nor/sfdp.c | 104 +++++++++++++++++++++++++++++++++++++++++++++

>  2 files changed, 124 insertions(+)

> 

> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h

> index a33f807..8de7f53 100644

> --- a/drivers/mtd/spi-nor/core.h

> +++ b/drivers/mtd/spi-nor/core.h

> @@ -183,6 +183,23 @@ struct spi_nor_locking_ops {

>  };

>  

>  /**

> + * struct cmd_seq_octal_dtr - command sequences to change to octal DTR mode

> + * Each command sequence is 8 per byte for single SPI mode.

> + * @len:	commmand length of each command sequence.

> + * @opcode:	command code.

> + * @addr:	address offset to device.

> + * @data:	data write to device.

> + */

> +struct cmd_seq_octal_dtr {

> +	u8 len;

> +	u8 opcode;

> +	u32 addr;

> +	u8 data;

> +};


You define seven bytes for the command sequence, while the table defines
eight bytes: first byte indicates the length of the sequence, and the
following seven bytes are values to be output by the controller.
How did you choose this cmd seq organization? The standard refers to the
7-byte sequence as "byte values to be output by the controller", it doesn't
indicate at which offset the opcode, addr and data are.

> +

> +#define CMD_SEQ_NUM	4

> +

> +/**

>   * struct spi_nor_flash_parameter - SPI NOR flash parameters and settings.

>   * Includes legacy flash parameters and settings that can be overwritten

>   * by the spi_nor_fixups hooks, or dynamically when parsing the JESD216

> @@ -205,6 +222,7 @@ struct spi_nor_locking_ops {

>   *                      higher index in the array, the higher priority.

>   * @erase_map:		the erase map parsed from the SFDP Sector Map Parameter

>   *                      Table.

> + * @cmd_seq:		command sequence to change to octal DTR mode.

>   * @quad_enable:	enables SPI NOR quad mode.

>   * @set_4byte_addr_mode: puts the SPI NOR in 4 byte addressing mode.

>   * @convert_addr:	converts an absolute address into something the flash

> @@ -232,6 +250,8 @@ struct spi_nor_flash_parameter {

>  

>  	struct spi_nor_erase_map        erase_map;

>  

> +	struct cmd_seq_octal_dtr	cmd_seq[CMD_SEQ_NUM];

> +

>  	int (*quad_enable)(struct spi_nor *nor);

>  	int (*set_4byte_addr_mode)(struct spi_nor *nor, bool enable);

>  	u32 (*convert_addr)(struct spi_nor *nor, u32 addr);

> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c

> index 27a4de4..ef19290 100644

> --- a/drivers/mtd/spi-nor/sfdp.c

> +++ b/drivers/mtd/spi-nor/sfdp.c

> @@ -21,6 +21,7 @@

>  #define SFDP_SECTOR_MAP_ID	0xff81	/* Sector Map Table */

>  #define SFDP_4BAIT_ID		0xff84  /* 4-byte Address Instruction Table */

>  #define SFDP_PROFILE1_ID	0xff05	/* xSPI Profile 1.0 table. */

> +#define SFDP_CMD_TO_8DTR_ID	0xff0a  /* Command Sequences to Octal DTR */

>  

>  #define SFDP_SIGNATURE		0x50444653U

>  #define SFDP_JESD216_MAJOR	1

> @@ -49,6 +50,19 @@ struct xspi_dummy_cycles {

>  	u8 shift;	/* Bit shift */

>  };

>  

> +#define CMD_TO_8DTR_LEN			GENMASK(31, 24)

> +#define CMD_TO_8DTR_OPCODE		GENMASK(23, 16)

> +#define CMD_TO_8DTR_1_ADDR		GENMASK(15, 8)

> +#define CMD_TO_8DTR_1_ADDR_DATA		GENMASK(7, 0)

> +#define CMD_TO_8DTR_4_ADDR_MSB		GENMASK(15, 0)

> +#define CMD_TO_8DTR_4_ADDR_LSB		GENMASK(31, 16)

> +#define CMD_TO_8DTR_4_ADDR_DATA		GENMASK(15, 8)

> +#define CMD_TO_8DTR_SIZE_MAX		8

> +

> +struct sfdp_cmd_to_8dtr {

> +	u32	dwords[CMD_TO_8DTR_SIZE_MAX];

> +};

> +

>  /* Basic Flash Parameter Table 20th DWORD, Max operation speed of device */

>  struct octal_max_speed {

>  	u8 idx; /* Bits value */

> @@ -1219,6 +1233,91 @@ static int spi_nor_parse_profile1(struct spi_nor *nor,

>  }

>  

>  /**

> + * spi_nor_parse_cmd_to_8dtr() - parse the command sequence to octal DTR

> + * @nor:		pointer to a 'struct spi_nor'

> + * @param_header:	command sequence to octal DTR parameter table header.

> + * @params:		pointer to the 'struct spi_nor_flash_parameter' to be.

> + *

> + * Return: 0 on success, -errno otherwise.

> + */

> +static int spi_nor_parse_cmd_to_8dtr(struct spi_nor *nor,

> +				     const struct sfdp_parameter_header *header,

> +				     struct spi_nor_flash_parameter *params)

> +{

> +	struct sfdp_cmd_to_8dtr cmd_seq;


you'll need to kmalloc cmd_seq because spi_nor_read_sfdp expects a DMA-able
buffer.

> +	u32 i, j, addr;

> +	size_t len;

> +	int ret;

> +

> +	if (header->major != SFDP_JESD216_MAJOR ||

> +	    header->length < CMD_TO_8DTR_SIZE_MAX)

> +		return -EINVAL;

> +

> +	len = min_t(size_t, sizeof(cmd_seq),

> +		    header->length * sizeof(u32));

> +

> +	memset(&cmd_seq, 0, sizeof(cmd_seq));


no need to set the contents to zero, cmd_seq will be overwritten with
the values read from sfdp.

> +

> +	addr = SFDP_PARAM_HEADER_PTP(header);

> +	ret = spi_nor_read_sfdp(nor, addr, len, &cmd_seq);

> +	if (ret)

> +		goto out;

> +

> +	/* Fix endianness of the Command Sequences to octal DTR. */

> +	le32_to_cpu_array(cmd_seq.dwords, CMD_TO_8DTR_SIZE_MAX);

> +

> +	memset(params->cmd_seq, 0, sizeof(params->cmd_seq[CMD_SEQ_NUM]));


params->cmd_seq is already filled with zeroes, no need to memset its
contents to zero

> +

> +	for (i = 0, j = 0;

> +	     i < CMD_SEQ_NUM && j < CMD_TO_8DTR_SIZE_MAX; i++, j += 2) {

> +		params->cmd_seq[i].len = FIELD_GET(CMD_TO_8DTR_LEN,

> +						   cmd_seq.dwords[j]);

> +		if (!params->cmd_seq[i].len)

> +			break;

> +

> +		switch (params->cmd_seq[i].len) {

> +		case 1:

> +			params->cmd_seq[i].opcode =

> +				FIELD_GET(CMD_TO_8DTR_OPCODE,

> +					  cmd_seq.dwords[j]);

> +			break;

> +

> +		case 3:

> +			params->cmd_seq[i].opcode =

> +				FIELD_GET(CMD_TO_8DTR_OPCODE,

> +					  cmd_seq.dwords[j]);

> +			params->cmd_seq[i].addr =

> +				FIELD_GET(CMD_TO_8DTR_1_ADDR,

> +					  cmd_seq.dwords[j]);

> +			params->cmd_seq[i].data =

> +				FIELD_GET(CMD_TO_8DTR_1_ADDR_DATA,

> +					  cmd_seq.dwords[j]);

> +			break;

> +

> +		case 6:

> +			params->cmd_seq[i].opcode =

> +				FIELD_GET(CMD_TO_8DTR_OPCODE,

> +					  cmd_seq.dwords[j]);

> +			params->cmd_seq[i].addr =

> +				FIELD_GET(CMD_TO_8DTR_4_ADDR_MSB,

> +					  cmd_seq.dwords[j]) << 16 |

> +				FIELD_GET(CMD_TO_8DTR_4_ADDR_LSB,

> +					  cmd_seq.dwords[j + 1]);

> +			params->cmd_seq[i].data =

> +				FIELD_GET(CMD_TO_8DTR_4_ADDR_DATA,

> +					  cmd_seq.dwords[j + 1]);

> +			break;


how should we treat case 2, 5 and 7? From where the assumptions on how
data is organized in the cmd sequence?

Thanks,
ta

> +

> +		default:

> +			break;

> +		}

> +	}

> +

> +out:

> +	return ret;

> +}

> +

> +/**

>   * spi_nor_parse_sfdp() - parse the Serial Flash Discoverable Parameters.

>   * @nor:		pointer to a 'struct spi_nor'

>   * @params:		pointer to the 'struct spi_nor_flash_parameter' to be

> @@ -1323,6 +1422,11 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,

>  			err = spi_nor_parse_profile1(nor, param_header, params);

>  			break;

>  

> +		case SFDP_CMD_TO_8DTR_ID:

> +			err = spi_nor_parse_cmd_to_8dtr(nor,

> +							param_header, params);

> +			break;

> +

>  		default:

>  			break;

>  		}

>
Tudor Ambarus Oct. 28, 2020, 10:25 a.m. UTC | #2
Hi, Mason, YC Lin,

On 5/29/20 10:36 AM, Mason Yang wrote:
> Macronix mx25uw51245g is a SPI NOR that supports 1-1-1/8-8-8 mode.

> 

> Correct the dummy cycles to device for various frequencies

> after xSPI profile 1.0 table parsed.

> 

> Enable mx25uw51245g to Octal DTR mode by executing the command sequences

> to change to octal DTR mode.

> 

> Signed-off-by: Mason Yang <masonccyang@mxic.com.tw>

> ---

>  drivers/mtd/spi-nor/macronix.c | 55 ++++++++++++++++++++++++++++++++++++++++++

>  1 file changed, 55 insertions(+)

> 

> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c

> index 96735d8..6c9a24c 100644

> --- a/drivers/mtd/spi-nor/macronix.c

> +++ b/drivers/mtd/spi-nor/macronix.c

> @@ -8,6 +8,57 @@

>  

>  #include "core.h"

>  

> +#define MXIC_CR2_DUMMY_SET_ADDR 0x300

> +

> +/* Fixup the dummy cycles to device and setup octa_dtr_enable() */

> +static void mx25uw51245g_post_sfdp_fixups(struct spi_nor *nor)

> +{

> +	struct spi_nor_flash_parameter *params = nor->params;

> +	int ret;

> +	u8 rdc, wdc;

> +

> +	ret = spi_nor_read_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, &rdc);


nor->bouncebuf is DMA-able, use it instead of rdc

> +	if (ret)

> +		return;

> +

> +	/* Refer to dummy cycle and frequency table(MHz) */

> +	switch (params->dummy_cycles) {

> +	case 10:	/* 10 dummy cycles for 104 MHz */

> +		wdc = 5;

> +		break;

> +	case 12:	/* 12 dummy cycles for 133 MHz */

> +		wdc = 4;

> +		break;

> +	case 16:	/* 16 dummy cycles for 166 MHz */

> +		wdc = 2;

> +		break;

> +	case 18:	/* 18 dummy cycles for 173 MHz */

> +		wdc = 1;

> +		break;

> +	case 20:	/* 20 dummy cycles for 200 MHz */

> +	default:

> +		wdc = 0;

> +	}

> +

> +	if (rdc != wdc)

> +		spi_nor_write_cr2(nor, MXIC_CR2_DUMMY_SET_ADDR, &wdc);

> +

> +	if (params->cmd_seq[0].len) {

> +		params->octal_dtr_enable = spi_nor_cmd_seq_octal_dtr;

> +		params->hwcaps.mask |= SNOR_HWCAPS_READ_8_8_8_DTR;

> +		params->hwcaps.mask |= SNOR_HWCAPS_PP_8_8_8_DTR;

> +

> +	} else {

> +		params->octal_dtr_enable = NULL;

> +		params->hwcaps.mask &= ~SNOR_HWCAPS_READ_8_8_8_DTR;

> +		params->hwcaps.mask &= ~SNOR_HWCAPS_PP_8_8_8_DTR;

> +	}

> +}

> +

> +static struct spi_nor_fixups mx25uw51245g_fixups = {

> +	.post_sfdp = mx25uw51245g_post_sfdp_fixups,

> +};

> +

>  static int

>  mx25l25635_post_bfpt_fixups(struct spi_nor *nor,

>  			    const struct sfdp_parameter_header *bfpt_header,

> @@ -84,6 +135,10 @@

>  			      SPI_NOR_QUAD_READ) },

>  	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048,

>  			      SPI_NOR_QUAD_READ) },

> +	{ "mx25uw51245g", INFO(0xc2813a, 0, 64 * 1024, 1024,

> +			      SECT_4K | SPI_NOR_4B_OPCODES |

> +			      SPI_NOR_OCTAL_DTR_READ)


octal dtr page program is supported?

> +			      .fixups = &mx25uw51245g_fixups },

>  };

>  

>  static void macronix_default_init(struct spi_nor *nor)

> 


Cheers,
ta
Tudor Ambarus Oct. 28, 2020, 10:42 a.m. UTC | #3
Hi, Mason, YC Lin,

We'll have to figure out how we can best use the "Command Sequences
to Change to Octal DDR" table.

Would be great if you continue to work on this. One has to
rebase this series on top of v5.10-rc1 with Pratyush's series [1]
applied in advance. Please let me know about your plans with this
series.

Cheers,
ta

[1] https://patchwork.ozlabs.org/project/linux-mtd/cover/20201005153138.6437-1-p.yadav@ti.com/