* [PATCH v4 0/4] Add octal DTR support for Macronix flash
@ 2021-10-18 6:24 JaimeLiao
2021-10-18 6:24 ` [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: JaimeLiao @ 2021-10-18 6:24 UTC (permalink / raw)
To: u-boot, jagan, vigneshr, p.yadav; +Cc: zhengxunli, jaimeliao, JaimeLiao
This series add support for Macronix octal DTR flash, add flag for
Softreset with "INVERT" command extension type on boot and follow
linux kernel to enable 4byte opcode when possible.
v4:
Add flag SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT to seperate command extension
types.
Replace ifdef with CONFIG_IS_ENABLED and modify uncorrect descriptions.
v3:
Add flag SPI_NOR_CMD_EXT_INVERT to seperate command extension types.
replace CONFIG_SPI_FLASH_MACRONIX with SPI_FLASH_MACRONIX_OCTAL for
spi_nor_macronix_octal_dtr_enable function.
v2:
add ret checking for write enable in spi_nor_macronix_octal_dtr_enable
function.
JaimeLiao (4):
mtd: spi-nor: macronix: add support for Macronix Octal
mtd: spi-nor-core: Adding different type of command extension in Soft
Reset
mtd: spi-nor-core: set 4byte opcode when possible
mtd: spi-nor-core: Add support for Macronix Octal flash
drivers/mtd/spi/Kconfig | 14 +++++
drivers/mtd/spi/spi-nor-core.c | 94 +++++++++++++++++++++++++++++++++-
drivers/mtd/spi/spi-nor-ids.c | 22 +++++++-
include/linux/mtd/spi-nor.h | 13 ++++-
4 files changed, 139 insertions(+), 4 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal 2021-10-18 6:24 [PATCH v4 0/4] Add octal DTR support for Macronix flash JaimeLiao @ 2021-10-18 6:24 ` JaimeLiao 2021-10-25 6:56 ` Jagan Teki 2021-10-18 6:24 ` [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset JaimeLiao ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: JaimeLiao @ 2021-10-18 6:24 UTC (permalink / raw) To: u-boot, jagan, vigneshr, p.yadav; +Cc: zhengxunli, jaimeliao, JaimeLiao Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding Macronix flash in Octal DTR mode. Enable Octal DTR mode with 20 dummy cycles to allow running at the maximum supported frequency. -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> --- drivers/mtd/spi/Kconfig | 7 +++ drivers/mtd/spi/spi-nor-core.c | 83 ++++++++++++++++++++++++++++++++++ include/linux/mtd/spi-nor.h | 13 +++++- 3 files changed, 101 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 1b2ef37e92..67599b32c9 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX help Add support for various Macronix SPI flash chips (MX25Lxxx) +config SPI_FLASH_MACRONIX_OCTAL + bool "Macronix octal flash support" + depends on SPI_FLASH_MACRONIX + help + Add support for the Macronix octal flash. This is a separate config + because the fixup hooks octal enable for this flash. + config SPI_FLASH_SPANSION bool "Spansion SPI flash support" help diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index d5d905fa5a..fdaca0a0d3 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3489,6 +3489,85 @@ static struct spi_nor_fixups mt35xu512aba_fixups = { }; #endif /* CONFIG_SPI_FLASH_MT35XU */ +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX_OCTAL) +/** + * spi_nor_macronix_octal_dtr_enable() - set DTR OPI Enable bit in Configuration Register 2. + * @nor: pointer to a 'struct spi_nor' + * + * Set the DTR OPI Enable (DOPI) bit in Configuration Register 2. + * Bit 2 of Configuration Register 2 is the DOPI bit for Macronix like OPI memories. + * + * Return: 0 on success, -errno otherwise. + */ +static int spi_nor_macronix_octal_dtr_enable(struct spi_nor *nor) +{ + struct spi_mem_op op; + int ret; + u8 buf; + + ret = write_enable(nor); + if (ret) + return ret; + + buf = SPINOR_REG_MXIC_DC_20; + op = (struct spi_mem_op) + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1), + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_DC, 1), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_DATA_OUT(1, &buf, 1)); + + ret = spi_mem_exec_op(nor->spi, &op); + if (ret) + return ret; + + ret = spi_nor_wait_till_ready(nor); + if (ret) + return ret; + + nor->read_dummy = MXIC_MAX_DC; + ret = write_enable(nor); + if (ret) + return ret; + + buf = SPINOR_REG_MXIC_OPI_DTR_EN; + op = (struct spi_mem_op) + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_CR2, 1), + SPI_MEM_OP_ADDR(4, SPINOR_REG_MXIC_CR2_MODE, 1), + SPI_MEM_OP_NO_DUMMY, + SPI_MEM_OP_DATA_OUT(1, &buf, 1)); + + ret = spi_mem_exec_op(nor->spi, &op); + if (ret) { + dev_err(nor->dev, "Failed to enable octal DTR mode\n"); + return ret; + } + nor->reg_proto = SNOR_PROTO_8_8_8_DTR; + + return 0; +} + +static void macronix_octal_default_init(struct spi_nor *nor) +{ + nor->octal_dtr_enable = spi_nor_macronix_octal_dtr_enable; +} + +static void macronix_octal_post_sfdp_fixup(struct spi_nor *nor, + struct spi_nor_flash_parameter *params) +{ + /* + * Adding SNOR_HWCAPS_PP_8_8_8_DTR in hwcaps.mask when + * SPI_NOR_OCTAL_DTR_READ flag exists. + */ + if (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 macronix_octal_fixups = { + .default_init = macronix_octal_default_init, + .post_sfdp = macronix_octal_post_sfdp_fixup, +}; +#endif /* CONFIG_SPI_FLASH_MACRONIX_OCTAL */ + /** spi_nor_octal_dtr_enable() - enable Octal DTR I/O if needed * @nor: pointer to a 'struct spi_nor' * @@ -3655,6 +3734,10 @@ void spi_nor_set_fixups(struct spi_nor *nor) if (!strcmp(nor->info->name, "mt35xu512aba")) nor->fixups = &mt35xu512aba_fixups; #endif + +#if CONFIG_IS_ENABLED(SPI_FLASH_MACRONIX_OCTAL) + nor->fixups = ¯onix_octal_fixups; +#endif /* SPI_FLASH_MACRONIX_OCTAL */ } int spi_nor_scan(struct spi_nor *nor) diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 7ddc4ba2bf..2ad579f66d 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -116,8 +116,17 @@ #define XSR_RDY BIT(7) /* Ready */ /* Used for Macronix and Winbond flashes. */ -#define SPINOR_OP_EN4B 0xb7 /* Enter 4-byte mode */ -#define SPINOR_OP_EX4B 0xe9 /* Exit 4-byte mode */ +#define SPINOR_OP_EN4B 0xb7 /* Enter 4-byte mode */ +#define SPINOR_OP_EX4B 0xe9 /* Exit 4-byte mode */ +#define SPINOR_OP_RD_CR2 0x71 /* Read configuration register 2 */ +#define SPINOR_OP_WR_CR2 0x72 /* Write configuration register 2 */ +#define SPINOR_OP_MXIC_DTR_RD 0xee /* Fast Read opcode in DTR mode */ +#define SPINOR_REG_MXIC_CR2_MODE 0x00000000 /* For setting octal DTR mode */ +#define SPINOR_REG_MXIC_OPI_DTR_EN 0x2 /* Enable Octal DTR */ +#define SPINOR_REG_MXIC_OPI_DTR_DIS 0x1 /* Disable Octal DTR */ +#define SPINOR_REG_MXIC_CR2_DC 0x00000300 /* For setting dummy cycles */ +#define SPINOR_REG_MXIC_DC_20 0x0 /* Setting dummy cycles to 20 */ +#define MXIC_MAX_DC 20 /* Maximum value of dummy cycles */ /* Used for Spansion flashes only. */ #define SPINOR_OP_BRWR 0x17 /* Bank register write */ -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal 2021-10-18 6:24 ` [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao @ 2021-10-25 6:56 ` Jagan Teki 2021-11-03 10:41 ` liao jaime 0 siblings, 1 reply; 17+ messages in thread From: Jagan Teki @ 2021-10-25 6:56 UTC (permalink / raw) To: JaimeLiao; +Cc: u-boot, vigneshr, p.yadav, zhengxunli, jaimeliao On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding > Macronix flash in Octal DTR mode. > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > maximum supported frequency. > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > --- > drivers/mtd/spi/Kconfig | 7 +++ > drivers/mtd/spi/spi-nor-core.c | 83 ++++++++++++++++++++++++++++++++++ > include/linux/mtd/spi-nor.h | 13 +++++- > 3 files changed, 101 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > index 1b2ef37e92..67599b32c9 100644 > --- a/drivers/mtd/spi/Kconfig > +++ b/drivers/mtd/spi/Kconfig > @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX > help > Add support for various Macronix SPI flash chips (MX25Lxxx) > > +config SPI_FLASH_MACRONIX_OCTAL What if we use exiting SPI_FLASH_MACRONIX for it? does it increasing size much? if not go for exiting macro. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal 2021-10-25 6:56 ` Jagan Teki @ 2021-11-03 10:41 ` liao jaime 2021-11-13 13:44 ` Jagan Teki 0 siblings, 1 reply; 17+ messages in thread From: liao jaime @ 2021-11-03 10:41 UTC (permalink / raw) To: Jagan Teki; +Cc: u-boot, vigneshr, Pratyush Yadav, zhengxunli, jaimeliao Hi Jagan > > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > > > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding > > Macronix flash in Octal DTR mode. > > > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > > maximum supported frequency. > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > --- > > drivers/mtd/spi/Kconfig | 7 +++ > > drivers/mtd/spi/spi-nor-core.c | 83 ++++++++++++++++++++++++++++++++++ > > include/linux/mtd/spi-nor.h | 13 +++++- > > 3 files changed, 101 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > index 1b2ef37e92..67599b32c9 100644 > > --- a/drivers/mtd/spi/Kconfig > > +++ b/drivers/mtd/spi/Kconfig > > @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX > > help > > Add support for various Macronix SPI flash chips (MX25Lxxx) > > > > +config SPI_FLASH_MACRONIX_OCTAL > > What if we use exiting SPI_FLASH_MACRONIX for it? does it increasing > size much? if not go for exiting macro. I want to seperate SPI_FLASH_MACRONIX and SPI_FLASH_MACRONIX_OCTAL for enabling Macronix octal support. Refer to your suggestions, checking SPI_FLASH_MACRONIX and other configuration which means octal enable is better. But I didn't found the existing configuration means "octal enable". It would be great if you can recommend the suitable configuration set for nor->fixups hooks macronix_octal_fixups. I will have v5 patchwork with the configuration checking. Thanks Jaime ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal 2021-11-03 10:41 ` liao jaime @ 2021-11-13 13:44 ` Jagan Teki 0 siblings, 0 replies; 17+ messages in thread From: Jagan Teki @ 2021-11-13 13:44 UTC (permalink / raw) To: liao jaime; +Cc: u-boot, vigneshr, Pratyush Yadav, zhengxunli, jaimeliao On Wed, Nov 3, 2021 at 4:11 PM liao jaime <jaimeliao.tw@gmail.com> wrote: > > Hi Jagan > > > > > > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > > > > > Follow patch "f6adec1af4b2f5d3012480c6cdce7743b74a6156" for adding > > > Macronix flash in Octal DTR mode. > > > > > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > > > maximum supported frequency. > > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > > --- > > > drivers/mtd/spi/Kconfig | 7 +++ > > > drivers/mtd/spi/spi-nor-core.c | 83 ++++++++++++++++++++++++++++++++++ > > > include/linux/mtd/spi-nor.h | 13 +++++- > > > 3 files changed, 101 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > > index 1b2ef37e92..67599b32c9 100644 > > > --- a/drivers/mtd/spi/Kconfig > > > +++ b/drivers/mtd/spi/Kconfig > > > @@ -162,6 +162,13 @@ config SPI_FLASH_MACRONIX > > > help > > > Add support for various Macronix SPI flash chips (MX25Lxxx) > > > > > > +config SPI_FLASH_MACRONIX_OCTAL > > > > What if we use exiting SPI_FLASH_MACRONIX for it? does it increasing > > size much? if not go for exiting macro. > I want to seperate SPI_FLASH_MACRONIX and SPI_FLASH_MACRONIX_OCTAL for > enabling Macronix octal support. > Refer to your suggestions, checking SPI_FLASH_MACRONIX and other > configuration which means octal enable is better. > But I didn't found the existing configuration means "octal enable". > It would be great if you can recommend the suitable configuration set > for nor->fixups hooks macronix_octal_fixups. > I will have v5 patchwork with the configuration checking. My suggestion is go with existing Macronix config, if we keep adding octal specific configs for each flash it will increase configs. Jagan. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset 2021-10-18 6:24 [PATCH v4 0/4] Add octal DTR support for Macronix flash JaimeLiao 2021-10-18 6:24 ` [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao @ 2021-10-18 6:24 ` JaimeLiao 2021-10-25 7:00 ` Jagan Teki 2021-10-18 6:24 ` [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible JaimeLiao 2021-10-18 6:24 ` [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash JaimeLiao 3 siblings, 1 reply; 17+ messages in thread From: JaimeLiao @ 2021-10-18 6:24 UTC (permalink / raw) To: u-boot, jagan, vigneshr, p.yadav; +Cc: zhengxunli, jaimeliao, JaimeLiao Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 8D-8D-8D in the begging of probe. Command extension type is not standardized across flash vendors in DTR mode. For suiting different vendor flash devices, adding a flag to seperate types for soft reset on boot. Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> --- drivers/mtd/spi/Kconfig | 7 +++++++ drivers/mtd/spi/spi-nor-core.c | 7 ++++++- 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index 67599b32c9..8304d6c973 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS can support a type of operation in a much more refined way compared to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc. +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT + bool "Command extension type is INVERT for Software Reset on boot" + default n + help + Because of SFDP information can not be get before boot. + So define command extension type is INVERT when Software Reset on boot only. + config SPI_FLASH_SOFT_RESET bool "Software Reset support for SPI NOR flashes" default n diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index fdaca0a0d3..87a7de7d60 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor) enum spi_nor_cmd_ext ext; ext = nor->cmd_ext_type; - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) { + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT) + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ + } op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), SPI_MEM_OP_NO_DUMMY, -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset 2021-10-18 6:24 ` [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset JaimeLiao @ 2021-10-25 7:00 ` Jagan Teki 2021-10-25 19:42 ` Pratyush Yadav 0 siblings, 1 reply; 17+ messages in thread From: Jagan Teki @ 2021-10-25 7:00 UTC (permalink / raw) To: JaimeLiao; +Cc: u-boot, vigneshr, p.yadav, zhengxunli, jaimeliao On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 8D-8D-8D > in the begging of probe. > > Command extension type is not standardized across flash vendors in DTR mode. > > For suiting different vendor flash devices, adding a flag to seperate types for > soft reset on boot. > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > --- > drivers/mtd/spi/Kconfig | 7 +++++++ > drivers/mtd/spi/spi-nor-core.c | 7 ++++++- > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > index 67599b32c9..8304d6c973 100644 > --- a/drivers/mtd/spi/Kconfig > +++ b/drivers/mtd/spi/Kconfig > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS > can support a type of operation in a much more refined way compared > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc. > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT > + bool "Command extension type is INVERT for Software Reset on boot" > + default n > + help > + Because of SFDP information can not be get before boot. > + So define command extension type is INVERT when Software Reset on boot only. > + > config SPI_FLASH_SOFT_RESET > bool "Software Reset support for SPI NOR flashes" > default n > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index fdaca0a0d3..87a7de7d60 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > enum spi_nor_cmd_ext ext; > > ext = nor->cmd_ext_type; > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) { > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT) > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try it that way instead of new macro? Jagan. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset 2021-10-25 7:00 ` Jagan Teki @ 2021-10-25 19:42 ` Pratyush Yadav 2021-10-26 6:42 ` liao jaime 2021-10-26 7:03 ` liao jaime 0 siblings, 2 replies; 17+ messages in thread From: Pratyush Yadav @ 2021-10-25 19:42 UTC (permalink / raw) To: Jagan Teki; +Cc: JaimeLiao, u-boot, vigneshr, zhengxunli, jaimeliao On 25/10/21 12:30PM, Jagan Teki wrote: > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 8D-8D-8D > > in the begging of probe. > > > > Command extension type is not standardized across flash vendors in DTR mode. > > > > For suiting different vendor flash devices, adding a flag to seperate types for > > soft reset on boot. > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > --- > > drivers/mtd/spi/Kconfig | 7 +++++++ > > drivers/mtd/spi/spi-nor-core.c | 7 ++++++- > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > index 67599b32c9..8304d6c973 100644 > > --- a/drivers/mtd/spi/Kconfig > > +++ b/drivers/mtd/spi/Kconfig > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS > > can support a type of operation in a much more refined way compared > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc. > > > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT > > + bool "Command extension type is INVERT for Software Reset on boot" > > + default n > > + help > > + Because of SFDP information can not be get before boot. > > + So define command extension type is INVERT when Software Reset on boot only. > > + > > config SPI_FLASH_SOFT_RESET > > bool "Software Reset support for SPI NOR flashes" > > default n > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > index fdaca0a0d3..87a7de7d60 100644 > > --- a/drivers/mtd/spi/spi-nor-core.c > > +++ b/drivers/mtd/spi/spi-nor-core.c > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > > enum spi_nor_cmd_ext ext; > > > > ext = nor->cmd_ext_type; > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) { > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT) > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ > > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try > it that way instead of new macro? The problem is that for OSPI boot mode the ROM can often leave the flash in 8D-8D-8D mode. So when U-Boot first starts executing the flash is already in 8D-8D-8D mode and there is no easy and reliable way to detect this mode. So we must blindly perform a soft reset before probing the flash and reading SFDP so that it is reset back to a usable state. This is why we can't detect the extension via BFPT since the flash is in an unknown state. This is not the case when resetting before booting the OS since at that point we have fully probed the flash. So I think this config must only be used for the reset at boot time. For later resets we should indeed use the extension provided by BFPT. This is a kinda hacky but I can't come up with a better alternative. Jamie, Below diff is what I have been suggesting you in my earlier replies. Note that this is just a quick and dirty implementation, I have not tested this at all. That is up to you to do. Please also test soft reset _after_ the probe is finished so we know that it works correctly when using data from BFPT as well. -- 8< -- diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 4388a08a90..b0f22e0ce5 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor) { struct spi_mem_op op; int ret; - enum spi_nor_cmd_ext ext; - - ext = nor->cmd_ext_type; - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), SPI_MEM_OP_NO_DUMMY, @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); - goto out; + return ret; } op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0), @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) ret = spi_mem_exec_op(nor->spi, &op); if (ret) { dev_warn(nor->dev, "Software reset failed: %d\n", ret); - goto out; + return ret; } /* @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) */ udelay(SPI_NOR_SRST_SLEEP_LEN); -out: - nor->cmd_ext_type = ext; - return ret; + return 0; } #endif /* CONFIG_SPI_FLASH_SOFT_RESET */ @@ -3698,6 +3692,44 @@ void spi_nor_set_fixups(struct spi_nor *nor) #endif } +/* + * When the flash is handed to us in a stateful mode like 8D-8D-8D, it is + * difficult to detect the mode the flash is in. One option is to read SFDP in + * all modes and see which one gives the correct "SFDP" signature, but not all + * flashes support SFDP in 8D-8D-8D mode. + * + * Further, even if you detect the mode of the flash via SFDP, you still have + * the problem of actually reading the ID. The Read ID command is not + * standardized across flash vendors. Flashes can have different dummy cycles + * needed for reading the ID. Some flashes even expect a 4-byte dummy address + * with the Read ID command. All this information cannot be obtained from the + * SFDP table. + * + * So, perform a Software Reset sequence before reading the ID and initializing + * the flash. A Soft Reset will bring back the flash in its default protocol + * mode assuming no non-volatile configuration was set. This will let us detect + * the flash even if ROM hands it to us in Octal DTR mode. + * + * To accommodate cases where there is more than one flash on a board, and only + * one of them needs a soft reset, failure to reset is not made fatal, and we + * still try to read ID if possible. + */ +static void spi_nor_soft_reset_on_boot(struct spi_nor *nor) +{ + enum spi_nor_cmd_ext ext; + + ext = nor->cmd_ext_type; + + if (CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)) + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; + else + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; + + spi_nor_soft_reset(nor); + + nor->cmd_ext_type = ext; +} + int spi_nor_scan(struct spi_nor *nor) { struct spi_nor_flash_parameter params; @@ -3722,32 +3754,8 @@ int spi_nor_scan(struct spi_nor *nor) nor->setup = spi_nor_default_setup; -#ifdef CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT - /* - * When the flash is handed to us in a stateful mode like 8D-8D-8D, it - * is difficult to detect the mode the flash is in. One option is to - * read SFDP in all modes and see which one gives the correct "SFDP" - * signature, but not all flashes support SFDP in 8D-8D-8D mode. - * - * Further, even if you detect the mode of the flash via SFDP, you - * still have the problem of actually reading the ID. The Read ID - * command is not standardized across flash vendors. Flashes can have - * different dummy cycles needed for reading the ID. Some flashes even - * expect a 4-byte dummy address with the Read ID command. All this - * information cannot be obtained from the SFDP table. - * - * So, perform a Software Reset sequence before reading the ID and - * initializing the flash. A Soft Reset will bring back the flash in - * its default protocol mode assuming no non-volatile configuration was - * set. This will let us detect the flash even if ROM hands it to us in - * Octal DTR mode. - * - * To accommodate cases where there is more than one flash on a board, - * and only one of them needs a soft reset, failure to reset is not - * made fatal, and we still try to read ID if possible. - */ - spi_nor_soft_reset(nor); -#endif /* CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT */ + if (CONFIG_IS_ENABLED(SPI_FLASH_SOFT_RESET_ON_BOOT)) + spi_nor_soft_reset_on_boot(nor); info = spi_nor_read_id(nor); if (IS_ERR_OR_NULL(info)) -- Regards, Pratyush Yadav Texas Instruments Inc. ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset 2021-10-25 19:42 ` Pratyush Yadav @ 2021-10-26 6:42 ` liao jaime 2021-10-26 7:03 ` liao jaime 1 sibling, 0 replies; 17+ messages in thread From: liao jaime @ 2021-10-26 6:42 UTC (permalink / raw) To: Pratyush Yadav; +Cc: Jagan Teki, u-boot, vigneshr, zhengxunli, jaimeliao For validating soft_reset after probe, I have test it on my side. It is working with command extension type which got from BFPT. Pratyush Yadav <p.yadav@ti.com> 於 2021年10月26日 週二 上午3:42寫道： > On 25/10/21 12:30PM, Jagan Teki wrote: > > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> > wrote: > > > > > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from > 8D-8D-8D > > > in the begging of probe. > > > > > > Command extension type is not standardized across flash vendors in DTR > mode. > > > > > > For suiting different vendor flash devices, adding a flag to seperate > types for > > > soft reset on boot. > > > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > > --- > > > drivers/mtd/spi/Kconfig | 7 +++++++ > > > drivers/mtd/spi/spi-nor-core.c | 7 ++++++- > > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > > index 67599b32c9..8304d6c973 100644 > > > --- a/drivers/mtd/spi/Kconfig > > > +++ b/drivers/mtd/spi/Kconfig > > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS > > > can support a type of operation in a much more refined way > compared > > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc. > > > > > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT > > > + bool "Command extension type is INVERT for Software Reset on > boot" > > > + default n > > > + help > > > + Because of SFDP information can not be get before boot. > > > + So define command extension type is INVERT when Software > Reset on boot only. > > > + > > > config SPI_FLASH_SOFT_RESET > > > bool "Software Reset support for SPI NOR flashes" > > > default n > > > diff --git a/drivers/mtd/spi/spi-nor-core.c > b/drivers/mtd/spi/spi-nor-core.c > > > index fdaca0a0d3..87a7de7d60 100644 > > > --- a/drivers/mtd/spi/spi-nor-core.c > > > +++ b/drivers/mtd/spi/spi-nor-core.c > > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor > *nor) > > > enum spi_nor_cmd_ext ext; > > > > > > ext = nor->cmd_ext_type; > > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) { > > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT) > > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ > > > > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try > > it that way instead of new macro? > > The problem is that for OSPI boot mode the ROM can often leave the flash > in 8D-8D-8D mode. So when U-Boot first starts executing the flash is > already in 8D-8D-8D mode and there is no easy and reliable way to detect > this mode. So we must blindly perform a soft reset before probing the > flash and reading SFDP so that it is reset back to a usable state. > > This is why we can't detect the extension via BFPT since the flash is in > an unknown state. This is not the case when resetting before booting the > OS since at that point we have fully probed the flash. So I think this > config must only be used for the reset at boot time. For later resets we > should indeed use the extension provided by BFPT. > > This is a kinda hacky but I can't come up with a better alternative. > > Jamie, > > Below diff is what I have been suggesting you in my earlier replies. > Note that this is just a quick and dirty implementation, I have not > tested this at all. That is up to you to do. Please also test soft reset > _after_ the probe is finished so we know that it works correctly when > using data from BFPT as well. > > -- 8< -- > diff --git a/drivers/mtd/spi/spi-nor-core.c > b/drivers/mtd/spi/spi-nor-core.c > index 4388a08a90..b0f22e0ce5 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > { > struct spi_mem_op op; > int ret; > - enum spi_nor_cmd_ext ext; > - > - ext = nor->cmd_ext_type; > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > op = (struct > spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), > SPI_MEM_OP_NO_DUMMY, > @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset enable failed: %d\n", > ret); > - goto out; > + return ret; > } > > op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, > 0), > @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset failed: %d\n", ret); > - goto out; > + return ret; > } > > /* > @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > */ > udelay(SPI_NOR_SRST_SLEEP_LEN); > > -out: > - nor->cmd_ext_type = ext; > - return ret; > + return 0; > } > #endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > > @@ -3698,6 +3692,44 @@ void spi_nor_set_fixups(struct spi_nor *nor) > #endif > } > > +/* > + * When the flash is handed to us in a stateful mode like 8D-8D-8D, it is > + * difficult to detect the mode the flash is in. One option is to read > SFDP in > + * all modes and see which one gives the correct "SFDP" signature, but > not all > + * flashes support SFDP in 8D-8D-8D mode. > + * > + * Further, even if you detect the mode of the flash via SFDP, you still > have > + * the problem of actually reading the ID. The Read ID command is not > + * standardized across flash vendors. Flashes can have different dummy > cycles > + * needed for reading the ID. Some flashes even expect a 4-byte dummy > address > + * with the Read ID command. All this information cannot be obtained from > the > + * SFDP table. > + * > + * So, perform a Software Reset sequence before reading the ID and > initializing > + * the flash. A Soft Reset will bring back the flash in its default > protocol > + * mode assuming no non-volatile configuration was set. This will let us > detect > + * the flash even if ROM hands it to us in Octal DTR mode. > + * > + * To accommodate cases where there is more than one flash on a board, > and only > + * one of them needs a soft reset, failure to reset is not made fatal, > and we > + * still try to read ID if possible. > + */ > +static void spi_nor_soft_reset_on_boot(struct spi_nor *nor) > +{ > + enum spi_nor_cmd_ext ext; > + > + ext = nor->cmd_ext_type; > + > + if (CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)) > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > + else > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > + > + spi_nor_soft_reset(nor); > + > + nor->cmd_ext_type = ext; > +} > + > int spi_nor_scan(struct spi_nor *nor) > { > struct spi_nor_flash_parameter params; > @@ -3722,32 +3754,8 @@ int spi_nor_scan(struct spi_nor *nor) > > nor->setup = spi_nor_default_setup; > > -#ifdef CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT > - /* > - * When the flash is handed to us in a stateful mode like > 8D-8D-8D, it > - * is difficult to detect the mode the flash is in. One option is > to > - * read SFDP in all modes and see which one gives the correct > "SFDP" > - * signature, but not all flashes support SFDP in 8D-8D-8D mode. > - * > - * Further, even if you detect the mode of the flash via SFDP, you > - * still have the problem of actually reading the ID. The Read ID > - * command is not standardized across flash vendors. Flashes can > have > - * different dummy cycles needed for reading the ID. Some flashes > even > - * expect a 4-byte dummy address with the Read ID command. All this > - * information cannot be obtained from the SFDP table. > - * > - * So, perform a Software Reset sequence before reading the ID and > - * initializing the flash. A Soft Reset will bring back the flash > in > - * its default protocol mode assuming no non-volatile > configuration was > - * set. This will let us detect the flash even if ROM hands it to > us in > - * Octal DTR mode. > - * > - * To accommodate cases where there is more than one flash on a > board, > - * and only one of them needs a soft reset, failure to reset is not > - * made fatal, and we still try to read ID if possible. > - */ > - spi_nor_soft_reset(nor); > -#endif /* CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT */ > + if (CONFIG_IS_ENABLED(SPI_FLASH_SOFT_RESET_ON_BOOT)) > + spi_nor_soft_reset_on_boot(nor); > > info = spi_nor_read_id(nor); > if (IS_ERR_OR_NULL(info)) > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset 2021-10-25 19:42 ` Pratyush Yadav 2021-10-26 6:42 ` liao jaime @ 2021-10-26 7:03 ` liao jaime 1 sibling, 0 replies; 17+ messages in thread From: liao jaime @ 2021-10-26 7:03 UTC (permalink / raw) To: Pratyush Yadav; +Cc: Jagan Teki, u-boot, vigneshr, zhengxunli, jaimeliao > > On 25/10/21 12:30PM, Jagan Teki wrote: > > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao <jaimeliao.tw@gmail.com> wrote: > > > > > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from 8D-8D-8D > > > in the begging of probe. > > > > > > Command extension type is not standardized across flash vendors in DTR mode. > > > > > > For suiting different vendor flash devices, adding a flag to seperate types for > > > soft reset on boot. > > > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > > --- > > > drivers/mtd/spi/Kconfig | 7 +++++++ > > > drivers/mtd/spi/spi-nor-core.c | 7 ++++++- > > > 2 files changed, 13 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > > > index 67599b32c9..8304d6c973 100644 > > > --- a/drivers/mtd/spi/Kconfig > > > +++ b/drivers/mtd/spi/Kconfig > > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS > > > can support a type of operation in a much more refined way compared > > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc. > > > > > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT > > > + bool "Command extension type is INVERT for Software Reset on boot" > > > + default n > > > + help > > > + Because of SFDP information can not be get before boot. > > > + So define command extension type is INVERT when Software Reset on boot only. > > > + > > > config SPI_FLASH_SOFT_RESET > > > bool "Software Reset support for SPI NOR flashes" > > > default n > > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > > index fdaca0a0d3..87a7de7d60 100644 > > > --- a/drivers/mtd/spi/spi-nor-core.c > > > +++ b/drivers/mtd/spi/spi-nor-core.c > > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > > > enum spi_nor_cmd_ext ext; > > > > > > ext = nor->cmd_ext_type; > > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) { > > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT) > > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */ > > > > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try > > it that way instead of new macro? > > The problem is that for OSPI boot mode the ROM can often leave the flash > in 8D-8D-8D mode. So when U-Boot first starts executing the flash is > already in 8D-8D-8D mode and there is no easy and reliable way to detect > this mode. So we must blindly perform a soft reset before probing the > flash and reading SFDP so that it is reset back to a usable state. > > This is why we can't detect the extension via BFPT since the flash is in > an unknown state. This is not the case when resetting before booting the > OS since at that point we have fully probed the flash. So I think this > config must only be used for the reset at boot time. For later resets we > should indeed use the extension provided by BFPT. > > This is a kinda hacky but I can't come up with a better alternative. > > Jamie, > > Below diff is what I have been suggesting you in my earlier replies. > Note that this is just a quick and dirty implementation, I have not > tested this at all. That is up to you to do. Please also test soft reset > _after_ the probe is finished so we know that it works correctly when > using data from BFPT as well. > > -- 8< -- > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index 4388a08a90..b0f22e0ce5 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > { > struct spi_mem_op op; > int ret; > - enum spi_nor_cmd_ext ext; > - > - ext = nor->cmd_ext_type; > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > > op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0), > SPI_MEM_OP_NO_DUMMY, > @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset enable failed: %d\n", ret); > - goto out; > + return ret; > } > > op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0), > @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > ret = spi_mem_exec_op(nor->spi, &op); > if (ret) { > dev_warn(nor->dev, "Software reset failed: %d\n", ret); > - goto out; > + return ret; > } > > /* > @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor) > */ > udelay(SPI_NOR_SRST_SLEEP_LEN); > > -out: > - nor->cmd_ext_type = ext; > - return ret; > + return 0; > } > #endif /* CONFIG_SPI_FLASH_SOFT_RESET */ > > @@ -3698,6 +3692,44 @@ void spi_nor_set_fixups(struct spi_nor *nor) > #endif > } > > +/* > + * When the flash is handed to us in a stateful mode like 8D-8D-8D, it is > + * difficult to detect the mode the flash is in. One option is to read SFDP in > + * all modes and see which one gives the correct "SFDP" signature, but not all > + * flashes support SFDP in 8D-8D-8D mode. > + * > + * Further, even if you detect the mode of the flash via SFDP, you still have > + * the problem of actually reading the ID. The Read ID command is not > + * standardized across flash vendors. Flashes can have different dummy cycles > + * needed for reading the ID. Some flashes even expect a 4-byte dummy address > + * with the Read ID command. All this information cannot be obtained from the > + * SFDP table. > + * > + * So, perform a Software Reset sequence before reading the ID and initializing > + * the flash. A Soft Reset will bring back the flash in its default protocol > + * mode assuming no non-volatile configuration was set. This will let us detect > + * the flash even if ROM hands it to us in Octal DTR mode. > + * > + * To accommodate cases where there is more than one flash on a board, and only > + * one of them needs a soft reset, failure to reset is not made fatal, and we > + * still try to read ID if possible. > + */ > +static void spi_nor_soft_reset_on_boot(struct spi_nor *nor) > +{ > + enum spi_nor_cmd_ext ext; > + > + ext = nor->cmd_ext_type; > + > + if (CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)) > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT; > + else > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT; > + > + spi_nor_soft_reset(nor); > + > + nor->cmd_ext_type = ext; > +} > + > int spi_nor_scan(struct spi_nor *nor) > { > struct spi_nor_flash_parameter params; > @@ -3722,32 +3754,8 @@ int spi_nor_scan(struct spi_nor *nor) > > nor->setup = spi_nor_default_setup; > > -#ifdef CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT > - /* > - * When the flash is handed to us in a stateful mode like 8D-8D-8D, it > - * is difficult to detect the mode the flash is in. One option is to > - * read SFDP in all modes and see which one gives the correct "SFDP" > - * signature, but not all flashes support SFDP in 8D-8D-8D mode. > - * > - * Further, even if you detect the mode of the flash via SFDP, you > - * still have the problem of actually reading the ID. The Read ID > - * command is not standardized across flash vendors. Flashes can have > - * different dummy cycles needed for reading the ID. Some flashes even > - * expect a 4-byte dummy address with the Read ID command. All this > - * information cannot be obtained from the SFDP table. > - * > - * So, perform a Software Reset sequence before reading the ID and > - * initializing the flash. A Soft Reset will bring back the flash in > - * its default protocol mode assuming no non-volatile configuration was > - * set. This will let us detect the flash even if ROM hands it to us in > - * Octal DTR mode. > - * > - * To accommodate cases where there is more than one flash on a board, > - * and only one of them needs a soft reset, failure to reset is not > - * made fatal, and we still try to read ID if possible. > - */ > - spi_nor_soft_reset(nor); > -#endif /* CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT */ > + if (CONFIG_IS_ENABLED(SPI_FLASH_SOFT_RESET_ON_BOOT)) > + spi_nor_soft_reset_on_boot(nor); > > info = spi_nor_read_id(nor); > if (IS_ERR_OR_NULL(info)) > > -- For validating soft_reset after probe, I have test it on my side. It is working with command extension type which got from BFPT. > Regards, > Pratyush Yadav > Texas Instruments Inc. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible 2021-10-18 6:24 [PATCH v4 0/4] Add octal DTR support for Macronix flash JaimeLiao 2021-10-18 6:24 ` [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao 2021-10-18 6:24 ` [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset JaimeLiao @ 2021-10-18 6:24 ` JaimeLiao 2021-10-25 19:44 ` Pratyush Yadav 2021-10-18 6:24 ` [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash JaimeLiao 3 siblings, 1 reply; 17+ messages in thread From: JaimeLiao @ 2021-10-18 6:24 UTC (permalink / raw) To: u-boot, jagan, vigneshr, p.yadav; +Cc: zhengxunli, jaimeliao, JaimeLiao Following linux kernel to check address width and 4byte flag to enable 4byte opcode setting. Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> --- drivers/mtd/spi/spi-nor-core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c index 87a7de7d60..7d6671ade2 100644 --- a/drivers/mtd/spi/spi-nor-core.c +++ b/drivers/mtd/spi/spi-nor-core.c @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor) return -EINVAL; } + /* Set 4byte opcodes when possible. */ + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES) + spi_nor_set_4byte_opcodes(nor, info); + /* Send all the required SPI flash commands to initialize device */ ret = spi_nor_init(nor); if (ret) -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible 2021-10-18 6:24 ` [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible JaimeLiao @ 2021-10-25 19:44 ` Pratyush Yadav 2021-10-26 7:00 ` liao jaime 0 siblings, 1 reply; 17+ messages in thread From: Pratyush Yadav @ 2021-10-25 19:44 UTC (permalink / raw) To: JaimeLiao; +Cc: u-boot, jagan, vigneshr, zhengxunli, jaimeliao On 18/10/21 02:24PM, JaimeLiao wrote: > Following linux kernel to check address width and 4byte flag to enable > 4byte opcode setting. > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > --- > drivers/mtd/spi/spi-nor-core.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > index 87a7de7d60..7d6671ade2 100644 > --- a/drivers/mtd/spi/spi-nor-core.c > +++ b/drivers/mtd/spi/spi-nor-core.c > @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor) > return -EINVAL; > } > > + /* Set 4byte opcodes when possible. */ > + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES) > + spi_nor_set_4byte_opcodes(nor, info); > + I still don't think this is the right thing to do. You should rework the previous check for SPI_NOR_4B_OPCODES to fit whatever your flash needs instead of adding it again. > /* Send all the required SPI flash commands to initialize device */ > ret = spi_nor_init(nor); > if (ret) > -- > 2.17.1 > -- Regards, Pratyush Yadav Texas Instruments Inc. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible 2021-10-25 19:44 ` Pratyush Yadav @ 2021-10-26 7:00 ` liao jaime 0 siblings, 0 replies; 17+ messages in thread From: liao jaime @ 2021-10-26 7:00 UTC (permalink / raw) To: Pratyush Yadav; +Cc: u-boot, Jagan Teki, vigneshr, zhengxunli, jaimeliao > > On 18/10/21 02:24PM, JaimeLiao wrote: > > Following linux kernel to check address width and 4byte flag to enable > > 4byte opcode setting. > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > --- > > drivers/mtd/spi/spi-nor-core.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > index 87a7de7d60..7d6671ade2 100644 > > --- a/drivers/mtd/spi/spi-nor-core.c > > +++ b/drivers/mtd/spi/spi-nor-core.c > > @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor) > > return -EINVAL; > > } > > > > + /* Set 4byte opcodes when possible. */ > > + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES) > > + spi_nor_set_4byte_opcodes(nor, info); > > + > > I still don't think this is the right thing to do. You should rework the > previous check for SPI_NOR_4B_OPCODES to fit whatever your flash needs > instead of adding it again. You are right, 3 byte command can be accepted after SPINOR_OP_EN4B. I will remove this part in patch next revision. > > > /* Send all the required SPI flash commands to initialize device */ > > ret = spi_nor_init(nor); > > if (ret) > > -- > > 2.17.1 > > > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash 2021-10-18 6:24 [PATCH v4 0/4] Add octal DTR support for Macronix flash JaimeLiao ` (2 preceding siblings ...) 2021-10-18 6:24 ` [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible JaimeLiao @ 2021-10-18 6:24 ` JaimeLiao 2021-10-25 19:45 ` Pratyush Yadav 3 siblings, 1 reply; 17+ messages in thread From: JaimeLiao @ 2021-10-18 6:24 UTC (permalink / raw) To: u-boot, jagan, vigneshr, p.yadav; +Cc: zhengxunli, jaimeliao, JaimeLiao Adding Macronix Octal flash for Octal DTR support. The octaflash series can be divided into the following types: MX25 series : Serial NOR Flash. MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. LW/UW series : Support simultaneous Read-while-Write operation in multiple bank architecture. Read-while-write feature which means read data one bank while another bank is programing or erasing. MX25LM : 3.0V Octal I/O -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf MX25UM : 1.8V Octal I/O -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf MX66LM : 3.0V Octal I/O with stacked die -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf MX66UM : 1.8V Octal I/O with stacked die -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf MX25LW : 3.0V Octal I/O with Read-while-Write MX25UW : 1.8V Octal I/O with Read-while-Write MX66LW : 3.0V Octal I/O with Read-while-Write and stack die MX66UW : 1.8V Octal I/O with Read-while-Write and stack die About LW/UW series, please contact us freely if you have any questions. For adding Octal NOR Flash IDs, we have validated each Flash on plateform zynq-picozed. Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> --- drivers/mtd/spi/spi-nor-ids.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c index cb3a08872d..5c13ea3a78 100644 --- a/drivers/mtd/spi/spi-nor-ids.c +++ b/drivers/mtd/spi/spi-nor-ids.c @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = { { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) }, { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) }, - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66lm1g45g", 0xc2853b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66um2g45g", 0xc2803c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66um1g45g", 0xc2803b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx66uw1g45g", 0xc2813b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw12345g", 0xc28438, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw6445g", 0xc28137, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, + { INFO("mx25uw6345g", 0xc28437, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, #endif #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ -- 2.17.1 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash 2021-10-18 6:24 ` [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash JaimeLiao @ 2021-10-25 19:45 ` Pratyush Yadav 2021-10-26 6:47 ` liao jaime 2021-10-26 7:02 ` liao jaime 0 siblings, 2 replies; 17+ messages in thread From: Pratyush Yadav @ 2021-10-25 19:45 UTC (permalink / raw) To: JaimeLiao; +Cc: u-boot, jagan, vigneshr, zhengxunli, jaimeliao On 18/10/21 02:24PM, JaimeLiao wrote: > Adding Macronix Octal flash for Octal DTR support. > > The octaflash series can be divided into the following types: > > MX25 series : Serial NOR Flash. > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. > LW/UW series : Support simultaneous Read-while-Write operation in multiple > bank architecture. Read-while-write feature which means read > data one bank while another bank is programing or erasing. > > MX25LM : 3.0V Octal I/O > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > MX25UM : 1.8V Octal I/O > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf > > MX66LM : 3.0V Octal I/O with stacked die > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf > > MX66UM : 1.8V Octal I/O with stacked die > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf > > MX25LW : 3.0V Octal I/O with Read-while-Write > MX25UW : 1.8V Octal I/O with Read-while-Write > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die > > About LW/UW series, please contact us freely if you have any > questions. For adding Octal NOR Flash IDs, we have validated > each Flash on plateform zynq-picozed. > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > --- > drivers/mtd/spi/spi-nor-ids.c | 22 +++++++++++++++++++++- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c > index cb3a08872d..5c13ea3a78 100644 > --- a/drivers/mtd/spi/spi-nor-ids.c > +++ b/drivers/mtd/spi/spi-nor-ids.c > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = { > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) }, > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) }, > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, Why are you changing the name of this flash? Other than this, the patch looks good to me. > + { INFO("mx66lm1g45g", 0xc2853b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx66um2g45g", 0xc2803c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx66um1g45g", 0xc2803b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx66uw1g45g", 0xc2813b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw12345g", 0xc28438, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw6445g", 0xc28137, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > + { INFO("mx25uw6345g", 0xc28437, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > #endif > > #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ > -- > 2.17.1 > -- Regards, Pratyush Yadav Texas Instruments Inc. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash 2021-10-25 19:45 ` Pratyush Yadav @ 2021-10-26 6:47 ` liao jaime 2021-10-26 7:02 ` liao jaime 1 sibling, 0 replies; 17+ messages in thread From: liao jaime @ 2021-10-26 6:47 UTC (permalink / raw) To: Pratyush Yadav; +Cc: u-boot, Jagan Teki, vigneshr, zhengxunli, jaimeliao MX66UW2G345G is similar to MX66UW2G345GX0 and MX66UW2G345G's device ID is 0xc2843c actually. So that I correct it and add MX66UW2G345GX0 in IDs table. Pratyush Yadav <p.yadav@ti.com> 於 2021年10月26日 週二 上午3:45寫道： > On 18/10/21 02:24PM, JaimeLiao wrote: > > Adding Macronix Octal flash for Octal DTR support. > > > > The octaflash series can be divided into the following types: > > > > MX25 series : Serial NOR Flash. > > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. > > LW/UW series : Support simultaneous Read-while-Write operation in > multiple > > bank architecture. Read-while-write feature which means > read > > data one bank while another bank is programing or erasing. > > > > MX25LM : 3.0V Octal I/O > > - > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > > > MX25UM : 1.8V Octal I/O > > - > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf > > > > MX66LM : 3.0V Octal I/O with stacked die > > - > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf > > > > MX66UM : 1.8V Octal I/O with stacked die > > - > https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf > > > > MX25LW : 3.0V Octal I/O with Read-while-Write > > MX25UW : 1.8V Octal I/O with Read-while-Write > > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die > > > > About LW/UW series, please contact us freely if you have any > > questions. For adding Octal NOR Flash IDs, we have validated > > each Flash on plateform zynq-picozed. > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > --- > > drivers/mtd/spi/spi-nor-ids.c | 22 +++++++++++++++++++++- > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mtd/spi/spi-nor-ids.c > b/drivers/mtd/spi/spi-nor-ids.c > > index cb3a08872d..5c13ea3a78 100644 > > --- a/drivers/mtd/spi/spi-nor-ids.c > > +++ b/drivers/mtd/spi/spi-nor-ids.c > > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = { > > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K | > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, > > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, > SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) }, > > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) }, > > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > Why are you changing the name of this flash? > > Other than this, the patch looks good to me. > > > + { INFO("mx66lm1g45g", 0xc2853b, 0, 32 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66um2g45g", 0xc2803c, 0, 64 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66um1g45g", 0xc2803b, 0, 32 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw1g45g", 0xc2813b, 0, 32 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12345g", 0xc28438, 0, 4 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw6445g", 0xc28137, 0, 2 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw6345g", 0xc28437, 0, 2 * 1024, 4096, SECT_4K | > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > #endif > > > > #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ > > -- > > 2.17.1 > > > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash 2021-10-25 19:45 ` Pratyush Yadav 2021-10-26 6:47 ` liao jaime @ 2021-10-26 7:02 ` liao jaime 1 sibling, 0 replies; 17+ messages in thread From: liao jaime @ 2021-10-26 7:02 UTC (permalink / raw) To: Pratyush Yadav; +Cc: u-boot, Jagan Teki, vigneshr, zhengxunli, jaimeliao > > On 18/10/21 02:24PM, JaimeLiao wrote: > > Adding Macronix Octal flash for Octal DTR support. > > > > The octaflash series can be divided into the following types: > > > > MX25 series : Serial NOR Flash. > > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb) > > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation. > > LW/UW series : Support simultaneous Read-while-Write operation in multiple > > bank architecture. Read-while-write feature which means read > > data one bank while another bank is programing or erasing. > > > > MX25LM : 3.0V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf > > > > MX25UM : 1.8V Octal I/O > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf > > > > MX66LM : 3.0V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf > > > > MX66UM : 1.8V Octal I/O with stacked die > > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf > > > > MX25LW : 3.0V Octal I/O with Read-while-Write > > MX25UW : 1.8V Octal I/O with Read-while-Write > > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die > > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die > > > > About LW/UW series, please contact us freely if you have any > > questions. For adding Octal NOR Flash IDs, we have validated > > each Flash on plateform zynq-picozed. > > > > Signed-off-by: JaimeLiao <jaimeliao.tw@gmail.com> > > --- > > drivers/mtd/spi/spi-nor-ids.c | 22 +++++++++++++++++++++- > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c > > index cb3a08872d..5c13ea3a78 100644 > > --- a/drivers/mtd/spi/spi-nor-ids.c > > +++ b/drivers/mtd/spi/spi-nor-ids.c > > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = { > > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, > > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES | SECT_4K) }, > > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) }, > > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > Why are you changing the name of this flash? > > Other than this, the patch looks good to me. MX66UW2G345G is similar to MX66UW2G345GX0 and MX66UW2G345G's device ID is 0xc2843c actually. So that I correct it and add MX66UW2G345GX0 in IDs table. > > > + { INFO("mx66lm1g45g", 0xc2853b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66um2g45g", 0xc2803c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66um1g45g", 0xc2803b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx66uw1g45g", 0xc2813b, 0, 32 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw12345g", 0xc28438, 0, 4 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw6445g", 0xc28137, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > + { INFO("mx25uw6345g", 0xc28437, 0, 2 * 1024, 4096, SECT_4K | SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) }, > > #endif > > > > #ifdef CONFIG_SPI_FLASH_STMICRO /* STMICRO */ > > -- > > 2.17.1 > > > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2021-11-13 13:44 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-18 6:24 [PATCH v4 0/4] Add octal DTR support for Macronix flash JaimeLiao 2021-10-18 6:24 ` [PATCH v4 1/4] mtd: spi-nor: macronix: add support for Macronix Octal JaimeLiao 2021-10-25 6:56 ` Jagan Teki 2021-11-03 10:41 ` liao jaime 2021-11-13 13:44 ` Jagan Teki 2021-10-18 6:24 ` [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset JaimeLiao 2021-10-25 7:00 ` Jagan Teki 2021-10-25 19:42 ` Pratyush Yadav 2021-10-26 6:42 ` liao jaime 2021-10-26 7:03 ` liao jaime 2021-10-18 6:24 ` [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible JaimeLiao 2021-10-25 19:44 ` Pratyush Yadav 2021-10-26 7:00 ` liao jaime 2021-10-18 6:24 ` [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash JaimeLiao 2021-10-25 19:45 ` Pratyush Yadav 2021-10-26 6:47 ` liao jaime 2021-10-26 7:02 ` liao jaime
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.