[PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix octal dtr operation

[zhengxunli at mxic.com.tw]

Hi,

"Pratyush Yadav" <p.yadav at ti.com> wrote on 2021/05/04 下午 03:42:20:

> "Pratyush Yadav" <p.yadav at ti.com> 
> 2021/05/04 下午 03:42
> 
> To
> 
> <zhengxunli at mxic.com.tw>, 
> 
> cc
> 
> <broonie at kernel.org>, <jaimeliao at mxic.com.tw>, <linux-
> mtd at lists.infradead.org>, <linux-spi at vger.kernel.org>, 
> <miquel.raynal at bootlin.com>, <tudor.ambarus at microchip.com>
> 
> Subject
> 
> Re: [PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix 
> octal dtr operation
> 
> On 04/05/21 01:31PM, zhengxunli at mxic.com.tw wrote:
> > Hi Pratyush,
> > 
> > Thanks for your comment on this patch.
> > 
> > "Pratyush Yadav" <p.yadav at ti.com> wrote on 2021/04/27 上午 10:36:06:
> > 
> [...]
> > > > +   if (!enable)
> > > > +      spi_nor_spimem_setup_op(nor, &op, SNOR_PROTO_8_8_8_DTR);
> > > 
> > > When disabling, the op would be in 8D-8D-8D mode so having a data 
length 
> > 
> > > of 1 would be invalid. This is currently the case even in the 
patches 
> > > that I sent for Micron and Cypress.
> > > 
> > > I am not sure what the correct fix for this is though. One option is 
to 
> > > send the same byte twice, but I remember that on the Cypress flash 
the 
> > > second byte over-writes the register at the next address. I'm not 
sure 
> > > how Macronix flashes handle the second byte. Can you check what the 
> > > behavior for your flash is when you write 2 bytes to the register?
> > 
> > I checked the behavior of Macronix and the second byte will overwrites 
the 
> > register.
> 
> Yes, I see the same behaviour on Micron and Cypress flashes. Can your 
> controller send a 1-byte write in 8D mode? I am curious if this is 
> possible and how flashes react to it.

Our SPI controller can not send 1 byte correctly in 8D mode. However, if 
we
send 2 bytes in 8D mode, the second byte will overwrite the first byte.

> My theory is that even if you ask the controller to send 1 byte in 8D 
> mode, it won't deassert the CS till the end of the cycle. This would 
> result the flash in taking the default value of the lines as the second 
> byte.
> 
> > Do we need to send the same bytes to resolve this error?
> 
> I think this is a design oversight by flash manufacturers. Having two 
> registers at consecutive addresses is problematic in 8D-8D-8D mode. The 
> only solution I see is to read the register at the next address, and set 

> its value as the second byte in the transaction. This way its value will 

> stay the same at the end of the transaction.
> 
> PS: If possible, please try to relay this issue to your hardware design 
> team. Hopefully they can come up with a clever solution for future 
> devices and make our lives easier ;-)

I will try to advise our design team. :=)

Thanks,
Zhengxun



CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================



============================================================================

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================