From: Pratyush Yadav <p.yadav@ti.com> To: <zhengxunli@mxic.com.tw> Cc: <broonie@kernel.org>, <jaimeliao@mxic.com.tw>, <linux-mtd@lists.infradead.org>, <linux-spi@vger.kernel.org>, <miquel.raynal@bootlin.com>, <tudor.ambarus@microchip.com> Subject: Re: [PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix octal dtr operation Date: Tue, 4 May 2021 13:12:20 +0530 [thread overview] Message-ID: <20210504074218.s2zezkt3imaanfmr@ti.com> (raw) In-Reply-To: <OF2365AB9C.87E8927D-ON482586CA.0029B8EB-482586CB.001E5C1A@mxic.com.tw> On 04/05/21 01:31PM, zhengxunli@mxic.com.tw wrote: > Hi Pratyush, > > Thanks for your comment on this patch. > > "Pratyush Yadav" <p.yadav@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. 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 ;-) -- Regards, Pratyush Yadav Texas Instruments Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Pratyush Yadav <p.yadav@ti.com> To: <zhengxunli@mxic.com.tw> Cc: <broonie@kernel.org>, <jaimeliao@mxic.com.tw>, <linux-mtd@lists.infradead.org>, <linux-spi@vger.kernel.org>, <miquel.raynal@bootlin.com>, <tudor.ambarus@microchip.com> Subject: Re: [PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix octal dtr operation Date: Tue, 4 May 2021 13:12:20 +0530 [thread overview] Message-ID: <20210504074218.s2zezkt3imaanfmr@ti.com> (raw) In-Reply-To: <OF2365AB9C.87E8927D-ON482586CA.0029B8EB-482586CB.001E5C1A@mxic.com.tw> On 04/05/21 01:31PM, zhengxunli@mxic.com.tw wrote: > Hi Pratyush, > > Thanks for your comment on this patch. > > "Pratyush Yadav" <p.yadav@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. 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 ;-) -- Regards, Pratyush Yadav Texas Instruments Inc. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-05-04 7:42 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-20 6:29 [PATCH v3 0/3] Add octal DTR support for Macronix flash Zhengxun Li 2021-04-20 6:29 ` Zhengxun Li 2021-04-20 6:29 ` [PATCH v3 1/3] mtd: spi-nor: macronix: add support for Macronix octal dtr operation Zhengxun Li 2021-04-20 6:29 ` Zhengxun Li 2021-04-27 2:36 ` Pratyush Yadav 2021-04-27 2:36 ` Pratyush Yadav 2021-05-04 5:31 ` zhengxunli 2021-05-04 5:31 ` zhengxunli 2021-05-04 7:42 ` Pratyush Yadav [this message] 2021-05-04 7:42 ` Pratyush Yadav 2021-05-05 8:29 ` zhengxunli 2021-05-05 8:29 ` zhengxunli 2021-04-20 6:29 ` [PATCH v3 2/3] mtd: spi-nor: macronix: add support for Macronix octaflash series Zhengxun Li 2021-04-20 6:29 ` Zhengxun Li 2021-04-27 2:47 ` Pratyush Yadav 2021-04-27 2:47 ` Pratyush Yadav 2021-05-04 5:38 ` zhengxunli 2021-05-04 5:38 ` zhengxunli 2021-04-20 6:29 ` [PATCH v3 3/3] spi: mxic: patch for octal DTR mode support Zhengxun Li 2021-04-20 6:29 ` Zhengxun Li 2021-04-26 16:53 ` Mark Brown 2021-04-26 16:53 ` Mark Brown 2021-04-27 1:48 ` zhengxunli 2021-04-27 1:48 ` zhengxunli
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=20210504074218.s2zezkt3imaanfmr@ti.com \ --to=p.yadav@ti.com \ --cc=broonie@kernel.org \ --cc=jaimeliao@mxic.com.tw \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-spi@vger.kernel.org \ --cc=miquel.raynal@bootlin.com \ --cc=tudor.ambarus@microchip.com \ --cc=zhengxunli@mxic.com.tw \ /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: linkBe 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.