From: masonccyang@mxic.com.tw To: "Miquel Raynal" <miquel.raynal@bootlin.com> Cc: bbrezillon@kernel.org, "Boris Brezillon" <boris.brezillon@collabora.com>, computersforpeace@gmail.com, dwmw2@infradead.org, frieder.schrempf@kontron.de, gregkh@linuxfoundation.org, juliensu@mxic.com.tw, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, marcel.ziswiler@toradex.com, marek.vasut@gmail.com, richard@nod.at, tglx@linutronix.de, vigneshr@ti.com Subject: Re: [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode Date: Wed, 16 Oct 2019 14:55:52 +0800 [thread overview] Message-ID: <OF7A229151.50591C54-ON48258495.00249AAF-48258495.002612F1@mxic.com.tw> (raw) In-Reply-To: <20191015095637.142e6db7@xps13> Hi Miquel, > > > > > > > > + nand_select_target(chip, 0); > > > > > > > > > > On several NAND controllers there is no way to act on the CS line > > > > > without actually writing bytes to the NAND chip. So basically this > > > > > is very likely to not work. > > > > > > > > any other way to make it work ? GPIO ? > > > > or just have some comments description here. > > > > i.e,. > > > > > > > > /* The NAND chip will exit the deep power down mode with #CS toggling, > > > > > > * please refer to datasheet for the timing requirement of tCRDP and > > tRDP. > > > > */ > > > > > > > > > > Good luck with that. As Miquel said, on most NAND controllers > > > select_target() is a dummy operation that just assigns nand_chip->target > > > to the specified value but doesn't assert the CS line. You could send a > > > dummy command here, like a READ_ID, but I guess you need CS to be > > > asserted for at least 20ns before asserting any other signals (CLE/ALE) > > > which might be an issue. > > > > okay, got it. > > But if possible, I think adding CS line control in nand_select_target() > > is a simple and generic way for MTD and all raw NAND controllers. > > The problem is not that we do not want to; the problem is that > controllers are not capable of doing it reliably if no byte is sent > over the NAND bus. okay, it's kind of pity even though our raw NAND controller is capable of doing it with no byte is sent over the NAND bus. As you mentioned that other controllers are not capable of doing it reliably if no byte is sent over the NAND bus. if so, does it work by adding a NAND_OP_DUMMY_INSTR ? (as Boris's comments) thanks for your time & comments. Mason 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. =====================================================================
WARNING: multiple messages have this Message-ID (diff)
From: masonccyang@mxic.com.tw To: "Miquel Raynal" <miquel.raynal@bootlin.com> Cc: vigneshr@ti.com, bbrezillon@kernel.org, juliensu@mxic.com.tw, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, frieder.schrempf@kontron.de, marcel.ziswiler@toradex.com, Boris Brezillon <boris.brezillon@collabora.com>, linux-mtd@lists.infradead.org, richard@nod.at, tglx@linutronix.de, computersforpeace@gmail.com, dwmw2@infradead.org, marek.vasut@gmail.com Subject: Re: [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode Date: Wed, 16 Oct 2019 14:55:52 +0800 [thread overview] Message-ID: <OF7A229151.50591C54-ON48258495.00249AAF-48258495.002612F1@mxic.com.tw> (raw) In-Reply-To: <20191015095637.142e6db7@xps13> Hi Miquel, > > > > > > > > + nand_select_target(chip, 0); > > > > > > > > > > On several NAND controllers there is no way to act on the CS line > > > > > without actually writing bytes to the NAND chip. So basically this > > > > > is very likely to not work. > > > > > > > > any other way to make it work ? GPIO ? > > > > or just have some comments description here. > > > > i.e,. > > > > > > > > /* The NAND chip will exit the deep power down mode with #CS toggling, > > > > > > * please refer to datasheet for the timing requirement of tCRDP and > > tRDP. > > > > */ > > > > > > > > > > Good luck with that. As Miquel said, on most NAND controllers > > > select_target() is a dummy operation that just assigns nand_chip->target > > > to the specified value but doesn't assert the CS line. You could send a > > > dummy command here, like a READ_ID, but I guess you need CS to be > > > asserted for at least 20ns before asserting any other signals (CLE/ALE) > > > which might be an issue. > > > > okay, got it. > > But if possible, I think adding CS line control in nand_select_target() > > is a simple and generic way for MTD and all raw NAND controllers. > > The problem is not that we do not want to; the problem is that > controllers are not capable of doing it reliably if no byte is sent > over the NAND bus. okay, it's kind of pity even though our raw NAND controller is capable of doing it with no byte is sent over the NAND bus. As you mentioned that other controllers are not capable of doing it reliably if no byte is sent over the NAND bus. if so, does it work by adding a NAND_OP_DUMMY_INSTR ? (as Boris's comments) thanks for your time & comments. Mason 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. ===================================================================== ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-10-16 6:56 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-18 7:56 [PATCH RFC 1/3] mtd: rawnand: Add support manufacturer postponed initialization Mason Yang 2019-09-18 7:56 ` Mason Yang 2019-09-18 7:56 ` [PATCH RFC 2/3] mtd: rawnand: Add support Macronix Block Protection function Mason Yang 2019-09-18 7:56 ` Mason Yang 2019-10-07 8:45 ` Miquel Raynal 2019-10-07 8:45 ` Miquel Raynal 2019-10-07 9:24 ` Miquel Raynal 2019-10-07 9:24 ` Miquel Raynal 2019-10-08 2:33 ` masonccyang 2019-10-08 2:33 ` masonccyang 2019-10-08 15:02 ` Miquel Raynal 2019-10-08 15:02 ` Miquel Raynal 2019-10-15 6:47 ` masonccyang 2019-10-15 6:47 ` masonccyang [not found] ` <OFB4F10613.467EB346-ON48258494.0020403E-48258494.002550A2@LocalDomain> 2019-10-21 7:23 ` masonccyang 2019-10-21 7:23 ` masonccyang 2019-10-21 7:44 ` Boris Brezillon 2019-10-21 7:44 ` Boris Brezillon 2019-10-21 8:40 ` masonccyang 2019-10-21 8:40 ` masonccyang 2019-10-21 8:56 ` Boris Brezillon 2019-10-21 8:56 ` Boris Brezillon 2019-10-21 9:07 ` masonccyang 2019-10-21 9:07 ` masonccyang 2019-09-18 7:56 ` [PATCH RFC 3/3] mtd: rawnand: Add support Macronix power down mode Mason Yang 2019-09-18 7:56 ` Mason Yang 2019-10-07 8:45 ` Miquel Raynal 2019-10-07 8:45 ` Miquel Raynal 2019-10-08 2:06 ` masonccyang 2019-10-08 2:06 ` masonccyang 2019-10-08 7:28 ` Boris Brezillon 2019-10-08 7:28 ` Boris Brezillon 2019-10-15 2:33 ` masonccyang 2019-10-15 2:33 ` masonccyang 2019-10-15 7:56 ` Miquel Raynal 2019-10-15 7:56 ` Miquel Raynal 2019-10-16 6:55 ` masonccyang [this message] 2019-10-16 6:55 ` masonccyang 2019-10-25 3:11 ` masonccyang 2019-10-25 3:11 ` masonccyang
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=OF7A229151.50591C54-ON48258495.00249AAF-48258495.002612F1@mxic.com.tw \ --to=masonccyang@mxic.com.tw \ --cc=bbrezillon@kernel.org \ --cc=boris.brezillon@collabora.com \ --cc=computersforpeace@gmail.com \ --cc=dwmw2@infradead.org \ --cc=frieder.schrempf@kontron.de \ --cc=gregkh@linuxfoundation.org \ --cc=juliensu@mxic.com.tw \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mtd@lists.infradead.org \ --cc=marcel.ziswiler@toradex.com \ --cc=marek.vasut@gmail.com \ --cc=miquel.raynal@bootlin.com \ --cc=richard@nod.at \ --cc=tglx@linutronix.de \ --cc=vigneshr@ti.com \ /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.