Re: [v9,23/28] mtd: spi-nor-core: Perform a Soft Reset on shutdown

[Pratyush Yadav <p.yadav@ti.com>]

Hi,

On 18/06/21 04:55PM, jaimeliao@mxic.com.tw wrote:
> 
> Hi Pratyush
> 
> 
> +#ifdef CONFIG_SPI_FLASH_SOFT_RESET
> +/**
> + * spi_nor_soft_reset() - perform the JEDEC Software Reset sequence
> + * @nor:                the spi_nor structure
> + *
> + * This function can be used to switch from Octal DTR mode to legacy mode 
> on a
> + * flash that supports it. The soft reset is executed in Octal DTR mode.
> + *
> + * Return: 0 for success, -errno for failure.
> + */
> +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;
> According JEDEC, cmd_ext_type has two different types, REPEAT and INVERT.
> Some Flash vendor using "INVERT" as cmd_ext_type so that it is not 
> suitable for hard coding the type as REPEAT.
> Sending twice reset command with different types is clumsy but useful 
> before read ID for getting Flash information.
> It would be great if you have any other ideas for this part.

It is possible to discover the extension type from BFPT (if the flash 
supports it, that is). But this function is supposed to be called before 
anything else to make sure the flash is in a sane state. For that 
reason, I don't think SFDP would be a viable approach.

Executing it twice might be a viable option. We need to see how flash 
that expect invert react to a repeat opcode, and vice versa.

Anyway, I don't think this is a problem for now. Both the 8D-8D-8D 
capable flashes supported with this series expect a repeat opcode.

> 
> +
> +                op = (struct 
> spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 0),
> +                                                SPI_MEM_OP_NO_DUMMY,
> +                                                SPI_MEM_OP_NO_ADDR,
> +                                                SPI_MEM_OP_NO_DATA);
> +                spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> +                ret = spi_mem_exec_op(nor->spi, &op);
> +                if (ret) {
> +                                dev_warn(nor->dev, "Software reset enable 
> failed: %d\n", ret);
> +                                goto out;
> +                }
> +
> +                op = (struct 
> spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0),
> +                                                SPI_MEM_OP_NO_DUMMY,
> +                                                SPI_MEM_OP_NO_ADDR,
> +                                                SPI_MEM_OP_NO_DATA);
> +                spi_nor_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> +                ret = spi_mem_exec_op(nor->spi, &op);
> +                if (ret) {
> +                                dev_warn(nor->dev, "Software reset 
> failed: %d\n", ret);
> +                                goto out;
> +                }
> +
> +                /*
> +                 * Software Reset is not instant, and the delay varies 
> from flash to
> +                 * flash. Looking at a few flashes, most range somewhere 
> below 100
> +                 * microseconds. So, wait for 200ms just to be sure.
> +                 */
> +                udelay(SPI_NOR_SRST_SLEEP_LEN);
> +
> +out:
> +                nor->cmd_ext_type = ext;
> +                return ret;
> +}
> 
> 
> Thanks
> Jaime

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.