From: Pratyush Yadav <p.yadav@ti.com>
To: <Tudor.Ambarus@microchip.com>
Cc: vigneshr@ti.com, richard@nod.at, nsekhar@ti.com,
linux-kernel@vger.kernel.org, boris.brezillon@collabora.com,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com
Subject: Re: [PATCH v13 11/15] mtd: spi-nor: core: perform a Soft Reset on shutdown
Date: Wed, 30 Sep 2020 13:13:09 +0530 [thread overview]
Message-ID: <20200930074307.rdi6352fy3is6gjq@ti.com> (raw)
In-Reply-To: <a32450dc-8db3-597c-34b0-68632ac27184@microchip.com>
On 30/09/20 07:32AM, Tudor.Ambarus@microchip.com wrote:
> On 9/29/20 4:08 PM, Pratyush Yadav wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > On 16/09/20 06:14PM, Pratyush Yadav wrote:
> >> Perform a Soft Reset on shutdown on flashes that support it so that the
> >> flash can be reset to its initial state and any configurations made by
> >> spi-nor (given that they're only done in volatile registers) will be
> >> reset. This will hand back the flash in pristine state for any further
> >> operations on it.
> >>
> >> Signed-off-by: Pratyush Yadav <p.yadav@ti.com>
> >> ---
> >> drivers/mtd/spi-nor/core.c | 41 +++++++++++++++++++++++++++++++++++++
> >> include/linux/mtd/spi-nor.h | 2 ++
> >> 2 files changed, 43 insertions(+)
> >>
> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> >> index 6ee93544d72f..853dfa02f0de 100644
> >> --- a/drivers/mtd/spi-nor/core.c
> >> +++ b/drivers/mtd/spi-nor/core.c
> >> @@ -40,6 +40,9 @@
> >>
> >> #define SPI_NOR_MAX_ADDR_WIDTH 4
> >>
> >> +#define SPI_NOR_SRST_SLEEP_MIN 200
> >> +#define SPI_NOR_SRST_SLEEP_MAX 400
> >> +
> >> /**
> >> * spi_nor_get_cmd_ext() - Get the command opcode extension based on the
> >> * extension type.
> >> @@ -3174,6 +3177,41 @@ static int spi_nor_init(struct spi_nor *nor)
> >> return 0;
> >> }
> >>
> >> +static void spi_nor_soft_reset(struct spi_nor *nor)
> >> +{
> >> + struct spi_mem_op op;
> >> + int ret;
> >> +
> >> + op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN, 8),
>
> can we avoid the cast?
No. The compiler complains about "expected expression before '{' token".
We can avoid it if the assignment is with the declaration but then we
can't re-use the variable op for the second command.
I like the cast better than using separate variables for the two (or
more in other cases) commands we execute.
> >
> > The buswidth used here should be 1 instead of 8. It makes no difference
> > in practice because the call to spi_nor_spimem_setup_op() immediately
> > after will over-write it to the correct value anyway, but let's follow
> > the style followed throughout the rest of the codebase. Will fix in the
> > next version.
>
> or you can just set the buswidth to 0 so that the reader rises his eyebrow
> and search for where it is updated. If you like it better you'll have to change
> throughout the entire code base, maybe in 4/15 where setup_op is introduced.
Ok. Will change it.
> >
> >> + SPI_MEM_OP_NO_DUMMY,
> >> + SPI_MEM_OP_NO_ADDR,
> >> + SPI_MEM_OP_NO_DATA);
> >> + spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
>
> Still not a big fan of this, but we can update the op init later on. How
> about some new lines around spi_nor_spimem_setup_op()? First time I read
> the code I haven't seen it.
Ok.
> >> + ret = spi_mem_exec_op(nor->spimem, &op);
> >> + if (ret) {
> >> + dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> >> + return;
> >> + }
> >> +
> >> + op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 8),
> >
> > Same here.
> >
> >> + SPI_MEM_OP_NO_DUMMY,
> >> + SPI_MEM_OP_NO_ADDR,
> >> + SPI_MEM_OP_NO_DATA);
> >> + spi_nor_spimem_setup_op(nor, &op, nor->reg_proto);
> >> + ret = spi_mem_exec_op(nor->spimem, &op);
> >> + if (ret) {
> >> + dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> >> + return;
> >> + }
> >> +
> >> + /*
> >> + * 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, sleep for a range of 200-400 us.
> >> + */
> >> + usleep_range(SPI_NOR_SRST_SLEEP_MIN, SPI_NOR_SRST_SLEEP_MAX);
> >> +}
> >> +
> >> /* mtd resume handler */
> >> static void spi_nor_resume(struct mtd_info *mtd)
> >> {
--
Regards,
Pratyush Yadav
Texas Instruments India
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-09-30 7:43 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-16 12:44 [PATCH v13 00/15] mtd: spi-nor: add xSPI Octal DTR support Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 01/15] mtd: spi-nor: core: use EOPNOTSUPP instead of ENOTSUPP Pratyush Yadav
2020-09-29 11:30 ` Tudor.Ambarus
2020-09-16 12:44 ` [PATCH v13 02/15] mtd: spi-nor: core: add spi_nor_{read, write}_reg() helpers Pratyush Yadav
2020-09-29 11:38 ` [PATCH v13 02/15] mtd: spi-nor: core: add spi_nor_{read,write}_reg() helpers Tudor.Ambarus
2020-09-29 12:54 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 03/15] mtd: spi-nor: core: add spi_nor_controller_ops_erase helper Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 04/15] mtd: spi-nor: add support for DTR protocol Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 05/15] mtd: spi-nor: sfdp: get command opcode extension type from BFPT Pratyush Yadav
2020-09-30 6:17 ` Tudor.Ambarus
2020-09-16 12:44 ` [PATCH v13 06/15] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table Pratyush Yadav
2020-09-30 6:44 ` Tudor.Ambarus
2020-09-30 6:53 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 07/15] mtd: spi-nor: core: use dummy cycle and address width info from SFDP Pratyush Yadav
2020-09-30 6:46 ` Tudor.Ambarus
2020-09-16 12:44 ` [PATCH v13 08/15] mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode Pratyush Yadav
2020-09-30 6:50 ` Tudor.Ambarus
2020-09-30 6:55 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 09/15] mtd: spi-nor: core: enable octal DTR mode when possible Pratyush Yadav
2020-09-29 11:26 ` Tudor.Ambarus
2020-09-29 12:51 ` Pratyush Yadav
2020-09-29 13:05 ` Tudor.Ambarus
2020-09-30 7:11 ` Tudor.Ambarus
2020-09-16 12:44 ` [PATCH v13 10/15] mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT Pratyush Yadav
2020-09-30 7:23 ` Tudor.Ambarus
2020-09-30 7:31 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 11/15] mtd: spi-nor: core: perform a Soft Reset on shutdown Pratyush Yadav
2020-09-29 13:08 ` Pratyush Yadav
2020-09-30 7:32 ` Tudor.Ambarus
2020-09-30 7:43 ` Pratyush Yadav [this message]
2020-09-16 12:44 ` [PATCH v13 12/15] mtd: spi-nor: core: disable Octal DTR mode on suspend Pratyush Yadav
2020-09-30 7:40 ` Tudor.Ambarus
2020-09-30 7:44 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 13/15] mtd: spi-nor: core: expose spi_nor_default_setup() in core.h Pratyush Yadav
2020-09-30 7:51 ` Tudor.Ambarus
2020-09-30 8:03 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 14/15] mtd: spi-nor: spansion: add support for Cypress Semper flash Pratyush Yadav
2020-09-30 8:36 ` Tudor.Ambarus
2020-09-30 12:32 ` Pratyush Yadav
2020-09-16 12:44 ` [PATCH v13 15/15] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode Pratyush Yadav
2020-09-30 9:12 ` Tudor.Ambarus
2020-09-29 9:59 ` [RFC PATCH 0/3] mtd: spi-nor: Tackle stateful modes Tudor Ambarus
2020-09-29 9:59 ` [RFC PATCH 1/3] mtd: spi-nor: Introduce SNOR_F_IO_MODE_EN_VOLATILE Tudor Ambarus
2020-09-29 16:45 ` Vignesh Raghavendra
2020-09-29 9:59 ` [RFC PATCH 2/3] mtd: spi-nor: Introduce MTD_SPI_NOR_ALLOW_STATEFUL_MODES Tudor Ambarus
2020-09-29 16:45 ` Vignesh Raghavendra
2020-09-29 9:59 ` [RFC PATCH 3/3] mtd: spi-nor: Parse SFDP SCCR Map Tudor Ambarus
2020-09-30 9:57 ` [PATCH v13 00/15] mtd: spi-nor: add xSPI Octal DTR support Tudor.Ambarus
2020-09-30 12:01 ` Pratyush Yadav
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200930074307.rdi6352fy3is6gjq@ti.com \
--to=p.yadav@ti.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=boris.brezillon@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=nsekhar@ti.com \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).