2018-08-20 11:26:36 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2012-09-28 00:58:06 +08:00
|
|
|
/*
|
|
|
|
* NAND Flash Controller Device Driver for DT
|
|
|
|
*
|
|
|
|
* Copyright © 2011, Picochip.
|
|
|
|
*/
|
2017-09-22 11:46:40 +08:00
|
|
|
|
2012-09-28 00:58:06 +08:00
|
|
|
#include <linux/clk.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>
|
2017-09-22 11:46:40 +08:00
|
|
|
#include <linux/platform_device.h>
|
2012-09-28 00:58:06 +08:00
|
|
|
|
|
|
|
#include "denali.h"
|
|
|
|
|
|
|
|
struct denali_dt {
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
struct denali_controller controller;
|
2018-06-23 00:06:37 +08:00
|
|
|
struct clk *clk; /* core clock */
|
|
|
|
struct clk *clk_x; /* bus interface clock */
|
|
|
|
struct clk *clk_ecc; /* ECC circuit clock */
|
2012-09-28 00:58:06 +08:00
|
|
|
};
|
|
|
|
|
2017-03-23 04:07:07 +08:00
|
|
|
struct denali_dt_data {
|
2017-03-30 14:45:57 +08:00
|
|
|
unsigned int revision;
|
2017-03-23 04:07:07 +08:00
|
|
|
unsigned int 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
|
|
|
const struct nand_ecc_caps *ecc_caps;
|
2017-03-23 04:07:07 +08:00
|
|
|
};
|
|
|
|
|
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);
|
2017-03-30 14:45:53 +08:00
|
|
|
static const struct denali_dt_data denali_socfpga_data = {
|
|
|
|
.caps = DENALI_CAP_HW_ECC_FIXUP,
|
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,
|
2017-03-30 14:45:53 +08:00
|
|
|
};
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2017-06-07 19:52:14 +08:00
|
|
|
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,
|
|
|
|
.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,
|
|
|
|
.ecc_caps = &denali_uniphier_v5b_ecc_caps,
|
|
|
|
};
|
|
|
|
|
2017-03-30 14:45:53 +08:00
|
|
|
static const struct of_device_id denali_nand_dt_ids[] = {
|
|
|
|
{
|
|
|
|
.compatible = "altr,socfpga-denali-nand",
|
|
|
|
.data = &denali_socfpga_data,
|
|
|
|
},
|
2017-06-07 19:52:14 +08:00
|
|
|
{
|
|
|
|
.compatible = "socionext,uniphier-denali-nand-v5a",
|
|
|
|
.data = &denali_uniphier_v5a_data,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.compatible = "socionext,uniphier-denali-nand-v5b",
|
|
|
|
.data = &denali_uniphier_v5b_data,
|
|
|
|
},
|
2017-03-30 14:45:53 +08:00
|
|
|
{ /* sentinel */ }
|
|
|
|
};
|
2012-09-28 00:58:06 +08:00
|
|
|
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
|
|
|
|
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Backward compatibility for old platforms */
|
|
|
|
static int denali_dt_legacy_chip_init(struct denali_controller *denali)
|
|
|
|
{
|
|
|
|
struct denali_chip *dchip;
|
|
|
|
int nsels, i;
|
|
|
|
|
|
|
|
nsels = denali->nbanks;
|
|
|
|
|
|
|
|
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++)
|
|
|
|
dchip->sels[i].bank = i;
|
|
|
|
|
|
|
|
nand_set_flash_node(&dchip->chip, denali->dev->of_node);
|
|
|
|
|
|
|
|
return denali_chip_init(denali, dchip);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check the DT binding.
|
|
|
|
* The new binding expects chip subnodes in the controller node.
|
|
|
|
* So, #address-cells = <1>; #size-cells = <0>; are required.
|
|
|
|
* Check the #size-cells to distinguish the binding.
|
|
|
|
*/
|
|
|
|
static bool denali_dt_is_legacy_binding(struct device_node *np)
|
|
|
|
{
|
|
|
|
u32 cells;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = of_property_read_u32(np, "#size-cells", &cells);
|
|
|
|
if (ret)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return cells != 0;
|
|
|
|
}
|
|
|
|
|
2017-03-30 14:45:56 +08:00
|
|
|
static int denali_dt_probe(struct platform_device *pdev)
|
2012-09-28 00:58:06 +08:00
|
|
|
{
|
2018-06-23 00:06:35 +08:00
|
|
|
struct device *dev = &pdev->dev;
|
2017-06-06 07:21:40 +08:00
|
|
|
struct resource *res;
|
2012-09-28 00:58:06 +08:00
|
|
|
struct denali_dt *dt;
|
2017-03-23 04:07:07 +08:00
|
|
|
const struct denali_dt_data *data;
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
struct denali_controller *denali;
|
|
|
|
struct device_node *np;
|
2012-09-28 00:58:06 +08:00
|
|
|
int ret;
|
|
|
|
|
2018-06-23 00:06:35 +08:00
|
|
|
dt = devm_kzalloc(dev, sizeof(*dt), GFP_KERNEL);
|
2012-09-28 00:58:06 +08:00
|
|
|
if (!dt)
|
|
|
|
return -ENOMEM;
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
denali = &dt->controller;
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2018-06-23 00:06:35 +08:00
|
|
|
data = of_device_get_match_data(dev);
|
2017-03-30 14:45:57 +08:00
|
|
|
if (data) {
|
|
|
|
denali->revision = data->revision;
|
2017-03-23 04:07:07 +08:00
|
|
|
denali->caps = data->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
|
|
|
denali->ecc_caps = data->ecc_caps;
|
2017-03-30 14:45:57 +08:00
|
|
|
}
|
2017-03-23 04:07:07 +08:00
|
|
|
|
2018-06-23 00:06:35 +08:00
|
|
|
denali->dev = dev;
|
2017-03-30 14:45:56 +08:00
|
|
|
denali->irq = platform_get_irq(pdev, 0);
|
2012-09-28 00:58:06 +08:00
|
|
|
if (denali->irq < 0) {
|
2018-06-23 00:06:35 +08:00
|
|
|
dev_err(dev, "no irq defined\n");
|
2013-03-18 17:41:13 +08:00
|
|
|
return denali->irq;
|
2012-09-28 00:58:06 +08:00
|
|
|
}
|
|
|
|
|
2017-06-06 07:21:40 +08:00
|
|
|
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "denali_reg");
|
2018-06-23 00:06:35 +08:00
|
|
|
denali->reg = devm_ioremap_resource(dev, res);
|
mtd: nand: denali: avoid magic numbers and rename for clarification
Introduce some macros and helpers to avoid magic numbers and
rename macros/functions for clarification.
- We see '| 2' in several places. This means Data Cycle in MAP11 mode.
The Denali User's Guide says bit[1:0] of MAP11 is like follows:
b'00 = Command Cycle
b'01 = Address Cycle
b'10 = Data Cycle
So, this commit added DENALI_MAP11_{CMD,ADDR,DATA} macros.
- We see 'denali->flash_mem + 0x10' in several places, but 0x10 is a
magic number. Actually, this accesses the data port of the Host
Data/Command Interface. So, this commit added DENALI_HOST_DATA.
On the other hand, 'denali->flash_mem' gets access to the address
port, so DENALI_HOST_ADDR was also added.
- We see 'index_addr(denali, cmd, 0x1)' in denali_erase(), but 0x1
is a magic number. 0x1 means the erase operation. Replace 0x1
with DENALI_ERASE.
- Rename index_addr() to denali_host_write() for clarification
- Denali User's Guide says MAP{00,01,10,11} for access mode. Match
the macros with terminology in the IP document.
- Rename struct members as follows:
flash_bank -> active_bank (currently selected bank)
flash_reg -> reg (base address of registers)
flash_mem -> host (base address of host interface)
devnum -> devs_per_cs (devices connected in parallel)
bbtskipbytes -> oob_skip_bytes (number of bytes to skip in OOB)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-16 13:36:39 +08:00
|
|
|
if (IS_ERR(denali->reg))
|
|
|
|
return PTR_ERR(denali->reg);
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2017-06-06 07:21:40 +08:00
|
|
|
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data");
|
2018-06-23 00:06:35 +08:00
|
|
|
denali->host = devm_ioremap_resource(dev, res);
|
mtd: nand: denali: avoid magic numbers and rename for clarification
Introduce some macros and helpers to avoid magic numbers and
rename macros/functions for clarification.
- We see '| 2' in several places. This means Data Cycle in MAP11 mode.
The Denali User's Guide says bit[1:0] of MAP11 is like follows:
b'00 = Command Cycle
b'01 = Address Cycle
b'10 = Data Cycle
So, this commit added DENALI_MAP11_{CMD,ADDR,DATA} macros.
- We see 'denali->flash_mem + 0x10' in several places, but 0x10 is a
magic number. Actually, this accesses the data port of the Host
Data/Command Interface. So, this commit added DENALI_HOST_DATA.
On the other hand, 'denali->flash_mem' gets access to the address
port, so DENALI_HOST_ADDR was also added.
- We see 'index_addr(denali, cmd, 0x1)' in denali_erase(), but 0x1
is a magic number. 0x1 means the erase operation. Replace 0x1
with DENALI_ERASE.
- Rename index_addr() to denali_host_write() for clarification
- Denali User's Guide says MAP{00,01,10,11} for access mode. Match
the macros with terminology in the IP document.
- Rename struct members as follows:
flash_bank -> active_bank (currently selected bank)
flash_reg -> reg (base address of registers)
flash_mem -> host (base address of host interface)
devnum -> devs_per_cs (devices connected in parallel)
bbtskipbytes -> oob_skip_bytes (number of bytes to skip in OOB)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-16 13:36:39 +08:00
|
|
|
if (IS_ERR(denali->host))
|
|
|
|
return PTR_ERR(denali->host);
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2018-06-23 00:06:37 +08:00
|
|
|
dt->clk = devm_clk_get(dev, "nand");
|
|
|
|
if (IS_ERR(dt->clk))
|
2012-09-28 00:58:06 +08:00
|
|
|
return PTR_ERR(dt->clk);
|
2018-06-23 00:06:37 +08:00
|
|
|
|
|
|
|
dt->clk_x = devm_clk_get(dev, "nand_x");
|
|
|
|
if (IS_ERR(dt->clk_x))
|
2019-01-15 16:11:34 +08:00
|
|
|
return PTR_ERR(dt->clk_x);
|
2018-06-23 00:06:37 +08:00
|
|
|
|
|
|
|
dt->clk_ecc = devm_clk_get(dev, "ecc");
|
|
|
|
if (IS_ERR(dt->clk_ecc))
|
2019-01-15 16:11:34 +08:00
|
|
|
return PTR_ERR(dt->clk_ecc);
|
2018-06-23 00:06:37 +08:00
|
|
|
|
2017-08-01 19:35:09 +08:00
|
|
|
ret = clk_prepare_enable(dt->clk);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2018-06-23 00:06:37 +08:00
|
|
|
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;
|
|
|
|
|
2019-01-15 16:11:34 +08:00
|
|
|
denali->clk_rate = clk_get_rate(dt->clk);
|
|
|
|
denali->clk_x_rate = clk_get_rate(dt->clk_x);
|
mtd: nand: denali: handle timing parameters by setup_data_interface()
Handling timing parameters in a driver's own way should be avoided
because it duplicates efforts of drivers/mtd/nand/nand_timings.c
Besides, this driver hard-codes Intel specific parameters such as
CLK_X=5, CLK_MULTI=4. Taking a certain device (Samsung K9WAG08U1A)
into account by get_samsung_nand_para() is weird as well.
Now, the core framework provides .setup_data_interface() hook, which
handles timing parameters in a generic manner.
While I am working on this, I found even more issues in the current
code, so fixed the following as well:
- In recent IP versions, WE_2_RE and TWHR2 share the same register.
Likewise for ADDR_2_DATA and TCWAW, CS_SETUP_CNT and TWB. When
updating one, the other must be masked. Otherwise, the other will
be set to 0, then timing settings will be broken.
- The recent IP release expanded the ADDR_2_DATA to 7-bit wide.
This register is related to tADL. As commit 74a332e78e8f ("mtd:
nand: timings: Fix tADL_min for ONFI 4.0 chips") addressed, the
ONFi 4.0 increased the minimum of tADL to 400 nsec. This may not
fit in the 6-bit ADDR_2_DATA in older versions. Check the IP
revision and handle this correctly, otherwise the register value
would wrap around.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-06-13 21:45:37 +08:00
|
|
|
|
2012-09-28 00:58:06 +08:00
|
|
|
ret = denali_init(denali);
|
|
|
|
if (ret)
|
2018-06-23 00:06:37 +08:00
|
|
|
goto out_disable_clk_ecc;
|
2012-09-28 00:58:06 +08:00
|
|
|
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
if (denali_dt_is_legacy_binding(dev->of_node)) {
|
|
|
|
ret = denali_dt_legacy_chip_init(denali);
|
|
|
|
if (ret)
|
|
|
|
goto out_remove_denali;
|
|
|
|
} else {
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-03-30 14:45:56 +08:00
|
|
|
platform_set_drvdata(pdev, dt);
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
|
2012-09-28 00:58:06 +08:00
|
|
|
return 0;
|
|
|
|
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
out_remove_denali:
|
|
|
|
denali_remove(denali);
|
2018-06-23 00:06:37 +08:00
|
|
|
out_disable_clk_ecc:
|
|
|
|
clk_disable_unprepare(dt->clk_ecc);
|
|
|
|
out_disable_clk_x:
|
|
|
|
clk_disable_unprepare(dt->clk_x);
|
2012-09-28 00:58:06 +08:00
|
|
|
out_disable_clk:
|
|
|
|
clk_disable_unprepare(dt->clk);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-03-30 14:45:56 +08:00
|
|
|
static int denali_dt_remove(struct platform_device *pdev)
|
2012-09-28 00:58:06 +08:00
|
|
|
{
|
2017-03-30 14:45:56 +08:00
|
|
|
struct denali_dt *dt = platform_get_drvdata(pdev);
|
2012-09-28 00:58:06 +08:00
|
|
|
|
mtd: rawnand: denali: decouple controller and NAND chips
Currently, this driver sticks to the legacy NAND model because it was
upstreamed before commit 2d472aba15ff ("mtd: nand: document the NAND
controller/NAND chip DT representation"). However, relying on the
dummy_controller is already deprecated.
Switch over to the new controller/chip representation.
The struct denali_nand_info has been split into denali_controller
and denali_chip, to contain the controller data, per-chip data,
respectively.
One problem is, this commit changes the DT binding. So, as always,
the backward compatibility must be taken into consideration.
In the new binding, the controller node expects
#address-cells = <1>;
#size-cells = <0>;
... since the child nodes represent NAND chips.
In the old binding, the controller node may have subnodes, but they
are MTD partitions.
The denali_dt_is_legacy_binding() exploits it to distinguish old/new
platforms.
Going forward, the old binding is only allowed for existing DT files.
I updated the binding document.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
2019-04-02 12:03:07 +08:00
|
|
|
denali_remove(&dt->controller);
|
2018-06-23 00:06:37 +08:00
|
|
|
clk_disable_unprepare(dt->clk_ecc);
|
|
|
|
clk_disable_unprepare(dt->clk_x);
|
2016-11-03 01:21:04 +08:00
|
|
|
clk_disable_unprepare(dt->clk);
|
2012-09-28 00:58:06 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct platform_driver denali_dt_driver = {
|
|
|
|
.probe = denali_dt_probe,
|
2012-11-20 02:21:24 +08:00
|
|
|
.remove = denali_dt_remove,
|
2012-09-28 00:58:06 +08:00
|
|
|
.driver = {
|
|
|
|
.name = "denali-nand-dt",
|
2013-03-18 17:41:14 +08:00
|
|
|
.of_match_table = denali_nand_dt_ids,
|
2012-09-28 00:58:06 +08:00
|
|
|
},
|
|
|
|
};
|
2013-03-18 17:41:12 +08:00
|
|
|
module_platform_driver(denali_dt_driver);
|
2012-09-28 00:58:06 +08:00
|
|
|
|
2018-08-20 11:26:36 +08:00
|
|
|
MODULE_LICENSE("GPL v2");
|
2012-09-28 00:58:06 +08:00
|
|
|
MODULE_AUTHOR("Jamie Iles");
|
|
|
|
MODULE_DESCRIPTION("DT driver for Denali NAND controller");
|