OpenCloudOS-Kernel/drivers/mtd/nand/raw/denali_dt.c

263 lines
6.2 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver for DT
*
* Copyright © 2011, Picochip.
*/
#include <linux/clk.h>
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>
2019-12-20 19:31:54 +08:00
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
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>
2019-12-20 19:31:54 +08:00
#include <linux/reset.h>
#include "denali.h"
struct denali_dt {
struct denali_controller controller;
struct clk *clk; /* core clock */
struct clk *clk_x; /* bus interface clock */
struct clk *clk_ecc; /* ECC circuit clock */
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>
2019-12-20 19:31:54 +08:00
struct reset_control *rst; /* core reset */
struct reset_control *rst_reg; /* register reset */
};
struct denali_dt_data {
unsigned int revision;
unsigned int caps;
unsigned int oob_skip_bytes;
mtd: nand: denali: avoid hard-coding ECC step, strength, bytes This driver was originally written for the Intel MRST platform with several platform-specific parameters hard-coded. Currently, the ECC settings are hard-coded as follows: #define ECC_SECTOR_SIZE 512 #define ECC_8BITS 14 #define ECC_15BITS 26 Therefore, the driver can only support two cases. - ecc.size = 512, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 512, ecc.strength = 15 --> ecc.bytes = 26 However, these are actually customizable parameters, for example, UniPhier platform supports the following: - ecc.size = 1024, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 1024, ecc.strength = 16 --> ecc.bytes = 28 - ecc.size = 1024, ecc.strength = 24 --> ecc.bytes = 42 So, we need to handle the ECC parameters in a more generic manner. Fortunately, the Denali User's Guide explains how to calculate the ecc.bytes. The formula is: ecc.bytes = 2 * CEIL(13 * ecc.strength / 16) (for ecc.size = 512) ecc.bytes = 2 * CEIL(14 * ecc.strength / 16) (for ecc.size = 1024) For DT platforms, it would be reasonable to allow DT to specify ECC strength by either "nand-ecc-strength" or "nand-ecc-maximize". If none of them is specified, the driver will try to meet the chip's ECC requirement. For PCI platforms, the max ECC strength is used to keep the original behavior. Newer versions of this IP need ecc.size and ecc.steps explicitly set up via the following registers: CFG_DATA_BLOCK_SIZE (0x6b0) CFG_LAST_DATA_BLOCK_SIZE (0x6c0) CFG_NUM_DATA_BLOCKS (0x6d0) For older IP versions, write accesses to these registers are just ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-07 19:52:12 +08:00
const struct nand_ecc_caps *ecc_caps;
};
mtd: nand: denali: avoid hard-coding ECC step, strength, bytes This driver was originally written for the Intel MRST platform with several platform-specific parameters hard-coded. Currently, the ECC settings are hard-coded as follows: #define ECC_SECTOR_SIZE 512 #define ECC_8BITS 14 #define ECC_15BITS 26 Therefore, the driver can only support two cases. - ecc.size = 512, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 512, ecc.strength = 15 --> ecc.bytes = 26 However, these are actually customizable parameters, for example, UniPhier platform supports the following: - ecc.size = 1024, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 1024, ecc.strength = 16 --> ecc.bytes = 28 - ecc.size = 1024, ecc.strength = 24 --> ecc.bytes = 42 So, we need to handle the ECC parameters in a more generic manner. Fortunately, the Denali User's Guide explains how to calculate the ecc.bytes. The formula is: ecc.bytes = 2 * CEIL(13 * ecc.strength / 16) (for ecc.size = 512) ecc.bytes = 2 * CEIL(14 * ecc.strength / 16) (for ecc.size = 1024) For DT platforms, it would be reasonable to allow DT to specify ECC strength by either "nand-ecc-strength" or "nand-ecc-maximize". If none of them is specified, the driver will try to meet the chip's ECC requirement. For PCI platforms, the max ECC strength is used to keep the original behavior. Newer versions of this IP need ecc.size and ecc.steps explicitly set up via the following registers: CFG_DATA_BLOCK_SIZE (0x6b0) CFG_LAST_DATA_BLOCK_SIZE (0x6c0) CFG_NUM_DATA_BLOCKS (0x6d0) For older IP versions, write accesses to these registers are just ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-07 19:52:12 +08:00
NAND_ECC_CAPS_SINGLE(denali_socfpga_ecc_caps, denali_calc_ecc_bytes,
512, 8, 15);
static const struct denali_dt_data denali_socfpga_data = {
.caps = DENALI_CAP_HW_ECC_FIXUP,
.oob_skip_bytes = 2,
mtd: nand: denali: avoid hard-coding ECC step, strength, bytes This driver was originally written for the Intel MRST platform with several platform-specific parameters hard-coded. Currently, the ECC settings are hard-coded as follows: #define ECC_SECTOR_SIZE 512 #define ECC_8BITS 14 #define ECC_15BITS 26 Therefore, the driver can only support two cases. - ecc.size = 512, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 512, ecc.strength = 15 --> ecc.bytes = 26 However, these are actually customizable parameters, for example, UniPhier platform supports the following: - ecc.size = 1024, ecc.strength = 8 --> ecc.bytes = 14 - ecc.size = 1024, ecc.strength = 16 --> ecc.bytes = 28 - ecc.size = 1024, ecc.strength = 24 --> ecc.bytes = 42 So, we need to handle the ECC parameters in a more generic manner. Fortunately, the Denali User's Guide explains how to calculate the ecc.bytes. The formula is: ecc.bytes = 2 * CEIL(13 * ecc.strength / 16) (for ecc.size = 512) ecc.bytes = 2 * CEIL(14 * ecc.strength / 16) (for ecc.size = 1024) For DT platforms, it would be reasonable to allow DT to specify ECC strength by either "nand-ecc-strength" or "nand-ecc-maximize". If none of them is specified, the driver will try to meet the chip's ECC requirement. For PCI platforms, the max ECC strength is used to keep the original behavior. Newer versions of this IP need ecc.size and ecc.steps explicitly set up via the following registers: CFG_DATA_BLOCK_SIZE (0x6b0) CFG_LAST_DATA_BLOCK_SIZE (0x6c0) CFG_NUM_DATA_BLOCKS (0x6d0) For older IP versions, write accesses to these registers are just ignored. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-07 19:52:12 +08:00
.ecc_caps = &denali_socfpga_ecc_caps,
};
NAND_ECC_CAPS_SINGLE(denali_uniphier_v5a_ecc_caps, denali_calc_ecc_bytes,
1024, 8, 16, 24);
static const struct denali_dt_data denali_uniphier_v5a_data = {
.caps = DENALI_CAP_HW_ECC_FIXUP |
DENALI_CAP_DMA_64BIT,
.oob_skip_bytes = 8,
.ecc_caps = &denali_uniphier_v5a_ecc_caps,
};
NAND_ECC_CAPS_SINGLE(denali_uniphier_v5b_ecc_caps, denali_calc_ecc_bytes,
1024, 8, 16);
static const struct denali_dt_data denali_uniphier_v5b_data = {
.revision = 0x0501,
.caps = DENALI_CAP_HW_ECC_FIXUP |
DENALI_CAP_DMA_64BIT,
.oob_skip_bytes = 8,
.ecc_caps = &denali_uniphier_v5b_ecc_caps,
};
static const struct of_device_id denali_nand_dt_ids[] = {
{
.compatible = "altr,socfpga-denali-nand",
.data = &denali_socfpga_data,
},
{
.compatible = "socionext,uniphier-denali-nand-v5a",
.data = &denali_uniphier_v5a_data,
},
{
.compatible = "socionext,uniphier-denali-nand-v5b",
.data = &denali_uniphier_v5b_data,
},
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
static int denali_dt_chip_init(struct denali_controller *denali,
struct device_node *chip_np)
{
struct denali_chip *dchip;
u32 bank;
int nsels, i, ret;
nsels = of_property_count_u32_elems(chip_np, "reg");
if (nsels < 0)
return nsels;
dchip = devm_kzalloc(denali->dev, struct_size(dchip, sels, nsels),
GFP_KERNEL);
if (!dchip)
return -ENOMEM;
dchip->nsels = nsels;
for (i = 0; i < nsels; i++) {
ret = of_property_read_u32_index(chip_np, "reg", i, &bank);
if (ret)
return ret;
dchip->sels[i].bank = bank;
nand_set_flash_node(&dchip->chip, chip_np);
}
return denali_chip_init(denali, dchip);
}
static int denali_dt_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct denali_dt *dt;
const struct denali_dt_data *data;
struct denali_controller *denali;
struct device_node *np;
int ret;
dt = devm_kzalloc(dev, sizeof(*dt), GFP_KERNEL);
if (!dt)
return -ENOMEM;
denali = &dt->controller;
data = of_device_get_match_data(dev);
if (WARN_ON(!data))
return -EINVAL;
denali->revision = data->revision;
denali->caps = data->caps;
denali->oob_skip_bytes = data->oob_skip_bytes;
denali->ecc_caps = data->ecc_caps;
denali->dev = dev;
denali->irq = platform_get_irq(pdev, 0);
if (denali->irq < 0)
return denali->irq;
denali->reg = devm_platform_ioremap_resource_byname(pdev, "denali_reg");
2017-06-16 13:36:39 +08:00
if (IS_ERR(denali->reg))
return PTR_ERR(denali->reg);
denali->host = devm_platform_ioremap_resource_byname(pdev, "nand_data");
2017-06-16 13:36:39 +08:00
if (IS_ERR(denali->host))
return PTR_ERR(denali->host);
dt->clk = devm_clk_get(dev, "nand");
if (IS_ERR(dt->clk))
return PTR_ERR(dt->clk);
dt->clk_x = devm_clk_get(dev, "nand_x");
if (IS_ERR(dt->clk_x))
return PTR_ERR(dt->clk_x);
dt->clk_ecc = devm_clk_get(dev, "ecc");
if (IS_ERR(dt->clk_ecc))
return PTR_ERR(dt->clk_ecc);
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>
2019-12-20 19:31:54 +08:00
dt->rst = devm_reset_control_get_optional_shared(dev, "nand");
if (IS_ERR(dt->rst))
return PTR_ERR(dt->rst);
dt->rst_reg = devm_reset_control_get_optional_shared(dev, "reg");
if (IS_ERR(dt->rst_reg))
return PTR_ERR(dt->rst_reg);
ret = clk_prepare_enable(dt->clk);
if (ret)
return ret;
ret = clk_prepare_enable(dt->clk_x);
if (ret)
goto out_disable_clk;
ret = clk_prepare_enable(dt->clk_ecc);
if (ret)
goto out_disable_clk_x;
denali->clk_rate = clk_get_rate(dt->clk);
denali->clk_x_rate = clk_get_rate(dt->clk_x);
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>
2019-12-20 19:31:54 +08:00
/*
* Deassert the register reset, and the core reset in this order.
* Deasserting the core reset while the register reset is asserted
* will cause unpredictable behavior in the controller.
*/
ret = reset_control_deassert(dt->rst_reg);
if (ret)
goto out_disable_clk_ecc;
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>
2019-12-20 19:31:54 +08:00
ret = reset_control_deassert(dt->rst);
if (ret)
goto out_assert_rst_reg;
/*
* When the reset is deasserted, the initialization sequence is kicked
* (bootstrap process). The driver must wait until it finished.
* Otherwise, it will result in unpredictable behavior.
*/
usleep_range(200, 1000);
ret = denali_init(denali);
if (ret)
goto out_assert_rst;
for_each_child_of_node(dev->of_node, np) {
ret = denali_dt_chip_init(denali, np);
if (ret) {
of_node_put(np);
goto out_remove_denali;
}
}
platform_set_drvdata(pdev, dt);
return 0;
out_remove_denali:
denali_remove(denali);
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>
2019-12-20 19:31:54 +08:00
out_assert_rst:
reset_control_assert(dt->rst);
out_assert_rst_reg:
reset_control_assert(dt->rst_reg);
out_disable_clk_ecc:
clk_disable_unprepare(dt->clk_ecc);
out_disable_clk_x:
clk_disable_unprepare(dt->clk_x);
out_disable_clk:
clk_disable_unprepare(dt->clk);
return ret;
}
static int denali_dt_remove(struct platform_device *pdev)
{
struct denali_dt *dt = platform_get_drvdata(pdev);
denali_remove(&dt->controller);
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>
2019-12-20 19:31:54 +08:00
reset_control_assert(dt->rst);
reset_control_assert(dt->rst_reg);
clk_disable_unprepare(dt->clk_ecc);
clk_disable_unprepare(dt->clk_x);
clk_disable_unprepare(dt->clk);
return 0;
}
static struct platform_driver denali_dt_driver = {
.probe = denali_dt_probe,
.remove = denali_dt_remove,
.driver = {
.name = "denali-nand-dt",
.of_match_table = denali_nand_dt_ids,
},
};
module_platform_driver(denali_dt_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Jamie Iles");
MODULE_DESCRIPTION("DT driver for Denali NAND controller");