[PATCH 2/2] mtd: spi-nor: Disable the flash quad mode in spi_nor_restore()

Matthias Weißer m.weisser.m at gmail.com
Tue Sep 1 06:08:36 EDT 2020


Am Di., 1. Sept. 2020 um 11:48 Uhr schrieb Pratyush Yadav <p.yadav at ti.com>:
> On 01/09/20 08:16AM, Matthias Weißer wrote:
> > Am Di., 16. Juni 2020 um 15:03 Uhr schrieb Yicong Yang
> > <yangyicong at hisilicon.com>:
> > > If the flash's quad mode is enabled, it'll remain in the quad mode when
> > > it's removed. If we drive the flash next time in SPI/Dual mode, then
> > > problem occurs as the flash's quad enable bit is not cleared.
> >
> > On flash devices with a non-volatile quad enable bit (we use S25FL512S)
> > this will wear out the quad enable bit as on every boot the bit is
> > set and reset on shutdown. Or do I miss something here?
>
> Yes, I think it will. If you always want the bit enabled (and it being
> non-volatile suggests that is the intended use), why not set
> nor->params->quad_enable() to NULL? That way it won't be touched at all,
> neither on boot nor on shutdown.

Because we want to use plain mainline kernel without any local patches.

> > > Disable the quad mode in spi_nor_restore(), the flash will leave
> > > quad mode when remove. This will make sure the flash always enter the
> > > correct mode when loaded.
> >
> > We have a system which relies on an enabled quad mode on boot
> > (bootloader uses quad mode without enabling it) so using this patch
> > will prevent our device from booting.
>
> Out of curiosity, how does the flash get detected by SPI NOR? It issues
> the Read ID command in 1S-1S-1S mode but the flash is expecting 1S-4S-4S
> commands. Do you have any extra patches applied to make it work?

The RDID command (0x9F) is always a 1S-1S-1S command regardless of the
QE bit state as e.g. the READ command (0x03). The only reason for the QE
bit is that it remaps the usage of the !WP and !HOLD signals to IO2 and IO3.

The SPI controller (QSPI on imx6 in our case) have to be programmed
accordingly to execute the RDID command in 1S-1S-1S mode but then the
state of the QE bit doesn't matter.

> I tried solving this problem for 8D-8D-8D mode but never really found a
> good solution.

I don't know your hardware but I am sure that should work that way to.

The current way it is done in your patch may wear out the QE bit (and
maybe others in status/configuration register) quite quickly if you
have a device which is booted frequently.

Regards,
Matthias



More information about the linux-mtd mailing list