Hi, "Pratyush Yadav" <p.yadav@xxxxxx> wrote on 2021/05/04 下午 03:42:20: > "Pratyush Yadav" <p.yadav@xxxxxx> > 2021/05/04 下午 03:42 > > To > > <zhengxunli@xxxxxxxxxxx>, > > cc > > <broonie@xxxxxxxxxx>, <jaimeliao@xxxxxxxxxxx>, <linux- > mtd@xxxxxxxxxxxxxxxxxxx>, <linux-spi@xxxxxxxxxxxxxxx>, > <miquel.raynal@xxxxxxxxxxx>, <tudor.ambarus@xxxxxxxxxxxxx> > > Subject > > Re: [PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix > octal dtr operation > > On 04/05/21 01:31PM, zhengxunli@xxxxxxxxxxx wrote: > > Hi Pratyush, > > > > Thanks for your comment on this patch. > > > > "Pratyush Yadav" <p.yadav@xxxxxx> 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. =====================================================================