From: <Tudor.Ambarus@microchip.com>
To: <boris.brezillon@collabora.com>
Cc: alexandre.belloni@bootlin.com, vigneshr@ti.com, richard@nod.at,
nsekhar@ti.com, Nicolas.Ferre@microchip.com,
linux-kernel@vger.kernel.org, Ludovic.Desroches@microchip.com,
broonie@kernel.org, linux-mtd@lists.infradead.org,
miquel.raynal@bootlin.com, linux-spi@vger.kernel.org,
p.yadav@ti.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Date: Tue, 12 May 2020 06:16:52 +0000 [thread overview]
Message-ID: <144878625.o7txgtY6sz@192.168.0.120> (raw)
In-Reply-To: <20200511112712.466f7246@collabora.com>
Hi, Boris, Pratyush,
I stripped case 2/, we'll not treat it for now.
On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, 11 May 2020 09:00:35 +0000
>
> <Tudor.Ambarus@microchip.com> wrote:
> > Hi, Pratyush, Boris,
> >
> > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote:
> > > This series adds support for octal DTR flashes in the spi-nor framework,
> >
> > I'm still learning about this, but I can give you my 2 cents as of now, to
> > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous
> > because the flash may not recover from unexpected resets. Entering one of
> > these modes can be:
> > 1/ volatile selectable, the device return to the 1-1-1 protocol after the
> > next power-on. I guess this is conditioned by the optional RESET pin, but
> > I'll have to check. Also the flash can return to the 1-1-1 mode using the
> > software reset or through writing to its Configuration Register, without
> > power-on or power- off.
>
> My understanding is that there's no standard software reset procedure
> that guarantees no conflict with existing 1S commands, so even the
> software reset approach doesn't work here.
>
The software reset procedure can't protect you from unexpected resets, but the
hardware with its optional reset pin can. Pratyush to confirm.
cut
>
> > Not recovering from unexpected resets is unacceptable. One should always
> > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with
> > the presence of the optional RESET pin.
>
> Totally agree with you on that one, but we know what happens in
> practice...
What I proposed is to condition the entering in the state-full modes with the
presence of the optional RESET pin. We would introduce an optional device tree
property for the RESET pin. If hardware doesn't implement the optional RESET#
signal, then we will not enter in the state-full modes.
Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <boris.brezillon@collabora.com>
Cc: <p.yadav@ti.com>, <alexandre.belloni@bootlin.com>,
<vigneshr@ti.com>, <richard@nod.at>, <nsekhar@ti.com>,
<Nicolas.Ferre@microchip.com>, <linux-kernel@vger.kernel.org>,
<Ludovic.Desroches@microchip.com>, <broonie@kernel.org>,
<linux-mtd@lists.infradead.org>, <miquel.raynal@bootlin.com>,
<linux-spi@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Date: Tue, 12 May 2020 06:16:52 +0000 [thread overview]
Message-ID: <144878625.o7txgtY6sz@192.168.0.120> (raw)
In-Reply-To: <20200511112712.466f7246@collabora.com>
Hi, Boris, Pratyush,
I stripped case 2/, we'll not treat it for now.
On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, 11 May 2020 09:00:35 +0000
>
> <Tudor.Ambarus@microchip.com> wrote:
> > Hi, Pratyush, Boris,
> >
> > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote:
> > > This series adds support for octal DTR flashes in the spi-nor framework,
> >
> > I'm still learning about this, but I can give you my 2 cents as of now, to
> > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous
> > because the flash may not recover from unexpected resets. Entering one of
> > these modes can be:
> > 1/ volatile selectable, the device return to the 1-1-1 protocol after the
> > next power-on. I guess this is conditioned by the optional RESET pin, but
> > I'll have to check. Also the flash can return to the 1-1-1 mode using the
> > software reset or through writing to its Configuration Register, without
> > power-on or power- off.
>
> My understanding is that there's no standard software reset procedure
> that guarantees no conflict with existing 1S commands, so even the
> software reset approach doesn't work here.
>
The software reset procedure can't protect you from unexpected resets, but the
hardware with its optional reset pin can. Pratyush to confirm.
cut
>
> > Not recovering from unexpected resets is unacceptable. One should always
> > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with
> > the presence of the optional RESET pin.
>
> Totally agree with you on that one, but we know what happens in
> practice...
What I proposed is to condition the entering in the state-full modes with the
presence of the optional RESET pin. We would introduce an optional device tree
property for the RESET pin. If hardware doesn't implement the optional RESET#
signal, then we will not enter in the state-full modes.
Cheers,
ta
WARNING: multiple messages have this Message-ID (diff)
From: <Tudor.Ambarus@microchip.com>
To: <boris.brezillon@collabora.com>
Cc: alexandre.belloni@bootlin.com, vigneshr@ti.com, richard@nod.at,
nsekhar@ti.com, linux-kernel@vger.kernel.org,
Ludovic.Desroches@microchip.com, broonie@kernel.org,
linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com,
linux-spi@vger.kernel.org, p.yadav@ti.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support
Date: Tue, 12 May 2020 06:16:52 +0000 [thread overview]
Message-ID: <144878625.o7txgtY6sz@192.168.0.120> (raw)
In-Reply-To: <20200511112712.466f7246@collabora.com>
Hi, Boris, Pratyush,
I stripped case 2/, we'll not treat it for now.
On Monday, May 11, 2020 12:27:12 PM EEST Boris Brezillon wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Mon, 11 May 2020 09:00:35 +0000
>
> <Tudor.Ambarus@microchip.com> wrote:
> > Hi, Pratyush, Boris,
> >
> > On Friday, April 24, 2020 9:43:54 PM EEST Pratyush Yadav wrote:
> > > This series adds support for octal DTR flashes in the spi-nor framework,
> >
> > I'm still learning about this, but I can give you my 2 cents as of now, to
> > open the discussion. Enabling 2-2-2, 4-4-4, and 8-8-8 modes is dangerous
> > because the flash may not recover from unexpected resets. Entering one of
> > these modes can be:
> > 1/ volatile selectable, the device return to the 1-1-1 protocol after the
> > next power-on. I guess this is conditioned by the optional RESET pin, but
> > I'll have to check. Also the flash can return to the 1-1-1 mode using the
> > software reset or through writing to its Configuration Register, without
> > power-on or power- off.
>
> My understanding is that there's no standard software reset procedure
> that guarantees no conflict with existing 1S commands, so even the
> software reset approach doesn't work here.
>
The software reset procedure can't protect you from unexpected resets, but the
hardware with its optional reset pin can. Pratyush to confirm.
cut
>
> > Not recovering from unexpected resets is unacceptable. One should always
> > prefer option 1/ and condition the entering in 2-2-2, 4-4-4 and 8-8-8 with
> > the presence of the optional RESET pin.
>
> Totally agree with you on that one, but we know what happens in
> practice...
What I proposed is to condition the entering in the state-full modes with the
presence of the optional RESET pin. We would introduce an optional device tree
property for the RESET pin. If hardware doesn't implement the optional RESET#
signal, then we will not enter in the state-full modes.
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-12 6:17 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 18:43 [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` [PATCH v4 01/16] spi: spi-mem: allow specifying whether an op is DTR or not Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` [PATCH v4 02/16] spi: atmel-quadspi: reject DTR ops Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-30 11:32 ` Mark Brown
2020-04-30 11:32 ` Mark Brown
2020-04-30 11:32 ` Mark Brown
2020-04-30 12:17 ` Pratyush Yadav
2020-04-30 12:17 ` Pratyush Yadav
2020-04-30 12:17 ` Pratyush Yadav
2020-04-30 12:19 ` Mark Brown
2020-04-30 12:19 ` Mark Brown
2020-04-30 12:19 ` Mark Brown
2020-04-24 18:43 ` [PATCH v4 03/16] spi: spi-mem: allow specifying a command's extension Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` [PATCH v4 04/16] mtd: spi-nor: add support for DTR protocol Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` [PATCH v4 05/16] mtd: spi-nor: default to address width of 3 for configurable widths Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-24 18:43 ` Pratyush Yadav
2020-04-26 3:53 ` Yicong Yang
2020-04-26 3:53 ` Yicong Yang
2020-04-26 3:53 ` Yicong Yang
2020-04-27 17:23 ` Pratyush Yadav
2020-04-27 17:23 ` Pratyush Yadav
2020-04-27 17:23 ` Pratyush Yadav
2020-04-28 1:34 ` Yicong Yang
2020-04-28 1:34 ` Yicong Yang
2020-04-28 1:34 ` Yicong Yang
2020-04-28 5:25 ` Tudor.Ambarus
2020-04-28 5:25 ` Tudor.Ambarus
2020-04-28 5:25 ` Tudor.Ambarus
2020-04-24 18:44 ` [PATCH v4 06/16] mtd: spi-nor: prepare BFPT parsing for JESD216 rev D Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 07/16] mtd: spi-nor: get command opcode extension type from BFPT Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 08/16] mtd: spi-nor: parse xSPI Profile 1.0 table Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 09/16] mtd: spi-nor: use dummy cycle and address width info from SFDP Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 10/16] mtd: spi-nor: do 2 byte reads for SR and FSR in DTR mode Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 11/16] mtd: spi-nor: enable octal DTR mode when possible Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 12/16] mtd: spi-nor: perform a Soft Reset on shutdown Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-05-10 11:22 ` Tudor.Ambarus
2020-05-10 11:22 ` Tudor.Ambarus
2020-05-10 11:22 ` Tudor.Ambarus
2020-05-11 18:01 ` Pratyush Yadav
2020-05-11 18:01 ` Pratyush Yadav
2020-05-11 18:01 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 13/16] mtd: spi-nor: Disable Octal DTR mode on suspend Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 14/16] mtd: spi-nor: expose spi_nor_default_setup() in core.h Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 15/16] mtd: spi-nor: add support for Cypress Semper flash Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` [PATCH v4 16/16] mtd: spi-nor: allow using MT35XU512ABA in Octal DTR mode Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-04-24 18:44 ` Pratyush Yadav
2020-05-11 9:00 ` [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support Tudor.Ambarus
2020-05-11 9:00 ` Tudor.Ambarus
2020-05-11 9:00 ` Tudor.Ambarus
2020-05-11 9:27 ` Boris Brezillon
2020-05-11 9:27 ` Boris Brezillon
2020-05-11 9:27 ` Boris Brezillon
2020-05-11 18:24 ` Pratyush Yadav
2020-05-11 18:24 ` Pratyush Yadav
2020-05-11 18:24 ` Pratyush Yadav
2020-05-12 6:16 ` Tudor.Ambarus [this message]
2020-05-12 6:16 ` Tudor.Ambarus
2020-05-12 6:16 ` Tudor.Ambarus
2020-05-12 9:49 ` Vignesh Raghavendra
2020-05-12 9:49 ` Vignesh Raghavendra
2020-05-12 9:49 ` Vignesh Raghavendra
2020-05-12 11:29 ` Tudor.Ambarus
2020-05-12 11:29 ` Tudor.Ambarus
2020-05-12 11:29 ` Tudor.Ambarus
2020-05-12 18:46 ` Pratyush Yadav
2020-05-12 18:46 ` Pratyush Yadav
2020-05-12 18:46 ` Pratyush Yadav
2020-05-11 9:43 ` Vignesh Raghavendra
2020-05-11 9:43 ` Vignesh Raghavendra
2020-05-11 9:43 ` Vignesh Raghavendra
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=144878625.o7txgtY6sz@192.168.0.120 \
--to=tudor.ambarus@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@collabora.com \
--cc=broonie@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=nsekhar@ti.com \
--cc=p.yadav@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 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.