From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
linux-mtd@lists.infradead.org
Cc: Marek Vasut <marex@denx.de>,
Vignesh Raghavendra <vigneshr@ti.com>,
Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org,
Ley Foon Tan <ley.foon.tan@intel.com>,
Dinh Nguyen <dinguyen@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: [PATCH v3 4/5] mtd: rawnand: denali_dt: add reset controlling
Date: Tue, 14 Jan 2020 18:06:00 +0100 [thread overview]
Message-ID: <20200114170600.1689-1-miquel.raynal@bootlin.com> (raw)
In-Reply-To: <20191220113155.28177-5-yamada.masahiro@socionext.com>
On Fri, 2019-12-20 at 11:31:54 UTC, Masahiro Yamada wrote:
> According to the Denali NAND Flash Memory Controller User's Guide,
> this IP has two reset signals.
>
> rst_n: reset most of FFs in the controller core
> reg_rst_n: reset all FFs in the register interface, and in the
> initialization sequencer
>
> This commit supports controlling those reset signals.
>
> It is possible to control them separately from the IP point of view
> although they might be often tied up together in actual SoC integration.
>
> The IP spec says, asserting only the reg_rst_n without asserting rst_n
> will cause unpredictable behavior in the controller. So, the driver
> deasserts ->rst_reg and ->rst in this order.
>
> Another thing that should be kept in mind is the automated initialization
> sequence (a.k.a. 'bootstrap' process) is kicked off when reg_rst_n is
> deasserted.
>
> When the reset is deasserted, the controller issues a RESET command
> to the chip select 0, and attempts to read out the chip ID, and further
> more, ONFI parameters if it is an ONFI-compliant device. Then, the
> controller sets up the relevant registers based on the detected
> device parameters.
>
> This process might be useful for tiny boot firmware, but is redundant
> for Linux Kernel because nand_scan_ident() probes devices and sets up
> parameters accordingly. Rather, this hardware feature is annoying
> because it ends up with misdetection due to bugs.
>
> So, commit 0615e7ad5d52 ("mtd: nand: denali: remove Toshiba and Hynix
> specific fixup code") changed the driver to not rely on it.
>
> However, there is no way to prevent it from running. The IP provides
> the 'bootstrap_inhibit_init' port to suppress this sequence, but it is
> usually out of software control, and dependent on SoC implementation.
> As for the Socionext UniPhier platform, LD4 always enables it. For the
> later SoCs, the bootstrap sequence runs depending on the boot mode.
>
> I added usleep_range() to make the driver wait until the sequence
> finishes. Otherwise, the driver would fail to detect the chip due
> to the race between the driver and hardware-controlled sequence.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-01-14 17:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-20 11:31 [PATCH v3 0/5] mtd: rawnand: denali: a bungle of denali patches that is cleanly applicable Masahiro Yamada
2019-12-20 11:31 ` [PATCH v3 1/5] mtd: rawnand: denali_dt: error out if platform has no associated data Masahiro Yamada
2020-01-14 17:06 ` Miquel Raynal
2019-12-20 11:31 ` [PATCH v3 2/5] mtd: rawnand: denali_dt: Add support for configuring SPARE_AREA_SKIP_BYTES Masahiro Yamada
2020-01-14 17:06 ` Miquel Raynal
2019-12-20 11:31 ` [PATCH v3 3/5] dt-bindings: mtd: denali_dt: document reset property Masahiro Yamada
2020-01-14 17:06 ` Miquel Raynal
2019-12-20 11:31 ` [PATCH v3 4/5] mtd: rawnand: denali_dt: add reset controlling Masahiro Yamada
2020-01-14 17:06 ` Miquel Raynal [this message]
2019-12-20 11:31 ` [PATCH v3 5/5] mtd: rawnand: denali: remove hard-coded DENALI_DEFAULT_OOB_SKIP_BYTES Masahiro Yamada
2020-01-14 17:05 ` Miquel Raynal
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=20200114170600.1689-1-miquel.raynal@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=dinguyen@kernel.org \
--cc=ley.foon.tan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=p.zabel@pengutronix.de \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=yamada.masahiro@socionext.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).