summaryrefslogtreecommitdiffstats
path: root/drivers/mtd/nand/raw/denali.c
diff options
context:
space:
mode:
authorMasahiro Yamada <yamada.masahiro@socionext.com>2019-12-20 20:31:54 +0900
committerMiquel Raynal <miquel.raynal@bootlin.com>2020-01-21 20:00:33 +0100
commit711fafc287e1be25b4420752062f852930e4c1d2 (patch)
tree9c012e5edf5190065a3aefae302b0f02c8d60656 /drivers/mtd/nand/raw/denali.c
parent48aad493e353db386ea8fc82f082220342e7e633 (diff)
downloadlinux-711fafc287e1be25b4420752062f852930e4c1d2.tar.bz2
mtd: rawnand: denali_dt: add reset controlling
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> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Diffstat (limited to 'drivers/mtd/nand/raw/denali.c')
0 files changed, 0 insertions, 0 deletions