Re: [PATCH v4 00/16] mtd: spi-nor: add xSPI Octal DTR support

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