The denali_cmdfunc() actually does nothing valuable for
NAND_CMD_{PAGEPROG,READ0,SEQIN}.

For NAND_CMD_{READ0,SEQIN}, it copies "page" to "denali->page", then
denali_read_page(_raw) compares them just for the sanity check.
(Inconsistently, this check is missing from denali_write_page(_raw).)

The Denali controller is equipped with high level read/write interface,
so let's skip unneeded call of cmdfunc().

If NAND_ECC_CUSTOM_PAGE_ACCESS is set, nand_write_page() will not
call ->waitfunc hook.  So, ->write_page(_raw) hooks should directly
return -EIO on failure.  The error handling of page writes will be
much simpler.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The Atmel NAND driver doesn't used anything from
linux/platform_data/atmel.h, stop including it.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Add two compatible strings for UniPhier SoC family.

"socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4,
Pro4, sLD8.

"socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2,
LD6b, LD11, LD20.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The Denali IP can automatically detect device parameters such as
page size, oob size, device width, etc. and this driver currently
relies on it.  However, this hardware function is known to be
problematic.

[1] Due to a hardware bug, various misdetected cases were reported.
    That is why get_toshiba_nand_para() and get_hynix_nand_para()
    exist to fix-up the misdetected parameters.  It is not realistic
    to add a new NAND device to the *black list* every time we are
    hit by a misdetected case.  We would never be able to guarantee
    that all cases are covered.

[2] Because this feature is unreliable, it is disabled on some
    platforms.

The nand_scan_ident() detects device parameters in a more tested
way.  The hardware should not set the device parameter registers in
a different, unreliable way.  Instead, set the parameters from the
nand_scan_ident() back to the registers.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

struct nand_ecc_caps was designed as flexible as possible to support
multiple stepsizes (like sunxi_nand.c).

So, we need to write multiple arrays even for the simplest case.
I guess many controllers support a single stepsize, so here is a
shorthand macro for the case.

It allows to describe like ...

NAND_ECC_CAPS_SINGLE(denali_pci_ecc_caps, denali_calc_ecc_bytes, 512, 8, 15);

... instead of

static const int denali_pci_ecc_strengths[] = {8, 15};
static const struct nand_ecc_step_info denali_pci_ecc_stepinfo = {
        .stepsize = 512,
        .strengths = denali_pci_ecc_strengths,
        .nstrengths = ARRAY_SIZE(denali_pci_ecc_strengths),
};
static const struct nand_ecc_caps denali_pci_ecc_caps = {
        .stepinfos = &denali_pci_ecc_stepinfo,
        .nstepinfos = 1,
        .calc_ecc_bytes = denali_calc_ecc_bytes,
};
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Driver are responsible for setting up ECC parameters correctly.
Those include:
  - Check if ECC parameters specified (usually by DT) are valid
  - Meet the chip's ECC requirement
  - Maximize ECC strength if NAND_ECC_MAXIMIZE flag is set

The logic can be generalized by factoring out common code.

This commit adds 3 helpers to the NAND framework:
nand_check_ecc_caps - Check if preset step_size and strength are valid
nand_match_ecc_req - Match the chip's requirement
nand_maximize_ecc - Maximize the ECC strength

To use the helpers above, a driver needs to provide:
  - Data array of supported ECC step size and strength
  - A hook that calculates ECC bytes from the combination of
    step_size and strength.

By using those helpers, code duplication among drivers will be
reduced.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Use BIT() and GENMASK() for register field macros.  This will make
it easier to compare the macros with the register description in the
Denali User's Guide.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

No need to use two struct resource pointers.  Just reuse one.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Signed-off-by: NMatthias Lange <matthias.lange@kernkonzept.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This makes it easier to grep.
Signed-off-by: NMatthias Lange <matthias.lange@kernkonzept.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

clk_prepare_enable() can fail here and we must check its return value.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

If we see unrecoverable ECC error, we need to count number of bitflips
from all-ones and report correctable/uncorrectable according to
that. Otherwise we report ECC failed on erased flash with single bit error.
Signed-off-by: NPavel Machek <pavel@denx.de>
Reported-by: NDarwin Dingel <Darwin.Dingel@alliedtelesis.co.nz>
Acked-by: NDarwin Dingel <Darwin.Dingel@alliedtelesis.co.nz>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

MT2712 NAND FLASH Controller is similar to MT2701 except those following:
(1) MT2712 supports up to 148B spare size per 1KB size sector (the same
    with 74B spare size per 512B size sector). There are three new spare
    format: 61, 67, 74.
(2) MT2712 supports up to 80 bit ecc strength. There are three new ecc
    strength level: 68, 72, 80.
(3) MT2712 ECC encode parity data register's start offset is 0x300, and
    different with 0x10 of MT2701.
(4) MT2712 improves ecc irq function. When ECC works in ECC_NFI_MODE,
    MT2701 will generate ecc irq number the same with ecc steps during
    page read. However, MT2712 can only generate one ecc irq.

Changes of this patch are:
(1) add two new variables named pg_irq_sel, encode_parity_reg0 in struct
    mtk_ecc_caps.
(2) add new bitfield ECC_PG_IRQ_SEL for register ECC_IRQ_REG.
(3) add ecc strength array of mt2712.
(4) add spare size array of mt2712.
(5) add mt2712 nfc and ecc device compatiable and data.
Signed-off-by: NXiaolei Li <xiaolei.li@mediatek.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

ECC strength and spare size supported may be different among MTK NAND
FLASH Controller IPs.

This patch contains changes as following:
(1) add new struct mtk_nfc_caps to support different spare size.
(2) add new struct mtk_ecc_caps to support different ecc strength.
(3) remove ECC_CNFG_xBIT define, use a for loop to do ecc strength config.
(4) remove PAGEFMT_SPARE_ define, use a for loop to do spare format config.
(5) malloc ecc->eccdata buffer according to max ecc strength of this IP.
Signed-off-by: NXiaolei Li <xiaolei.li@mediatek.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The register NFI_PAGEFMT is always 32 bits length, so it is better to
do register program using writel() compare with writew().
Signed-off-by: NXiaolei Li <xiaolei.li@mediatek.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Add MT2712 NAND Flash Controller dt bindings documentation.
Signed-off-by: NXiaolei Li <xiaolei.li@mediatek.com>
Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The newly added suspend/resume support causes a harmless warning:

drivers/mtd/nand/atmel/nand-controller.c:2513:12: error: 'atmel_nand_controller_resume' defined but not used [-Werror=unused-function]

This shuts up the warning with a __maybe_unused annotation.

Fixes: b107007a7114 ("mtd: nand: atmel: Add PM ops")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Drivers are supposed to set correct ecc->{size,strength,bytes} before
calling nand_scan_tail(), but it does not complain about ecc->total
bigger than oobsize.

In this case, chip->scan_bbt() crashes due to memory corruption, but
it is hard to debug.  It would be kind to fail it earlier with a clear
message.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

READ0 is sometimes used to exit GET STATUS mode. When this is the case
no address cycles are requested, and we can use this information to
detect that READSTART should not be issued after READ0 or that we
shouldn't wait for the chip to be ready.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Drivers setting NAND_ECC_CUSTOM_PAGE_ACCESS are supposed to handle the
full read/write page sequence, and waiting for a page to actually be
programmed is part of this write-page sequence.
This is also what is done in ->write_oob_xxx() hooks, so let's do that in
->write_page_xxx() as well to make it consistent.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

SEQIN is supposed to be used when one wants to start programming a page.
What we want here is just to change the column within the page, which is
done with the RNDIN command.

Fixes: 6956e238 ("mtd: nand: add tango NAND flash controller support")
Cc: stable@vger.kernel.org
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: NMarc Gonzalez <marc_gonzalez@sigmadesigns.com>

The core already sends the NAND_CMD_READ0 for us. Duplicating this call
in the driver is useless and introduces a perf penalty.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

ecc->read_subpage is set to sunxi_nfc_hw_ecc_read_subpage_dma when
->dmac != NULL, but is then unconditionally overwritten in the common
init path.

Remove this extra assignment to allow usage of the DMA operation when
possible.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The ->errstat() hook is no longer implemented NAND controller drivers.
Get rid of it before someone starts abusing it.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Cached programming is always skipped, so drop the associated code until
we decide to really support it.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Provide a ->resume() hook to make sure the NAND timings are correctly
restored by resetting all chips connected to the controller.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The NAND controller IP can adapt the NAND controller timings dynamically.
Implement the ->setup_data_interface() hook to support this feature.

Note that it's not supported on at91rm9200 because this SoC has a
completely different SMC block, which is not supported yet.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Some NAND controllers can assign different NAND timings to different
CS lines. Pass the CS line information to ->setup_data_interface() so
that the NAND controller driver knows which CS line is concerned by
the setup_data_interface() request.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

The only user of gpmi_nand_exit() is gpmi_nand_remove(). Move its content
to the caller.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Acked-by: NHan Xu <han.xu@nxp.com>

The GPMI driver is wrongly assuming that nand_release() can safely be
called on an uninitialized/unregistered NAND device.

Add a new err_nand_cleanup label in the error path and only execute if
nand_scan_tail() succeeded.

Note that we now call nand_cleanup() instead of nand_release()
(nand_release() is actually grouping the mtd_device_unregister() and
nand_cleanup() in one call) because there's no point in trying to
unregister a device that has never been registered.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Acked-by: NHan Xu <han.xu@nxp.com>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>

The clock requirements are completely missing, add the clocks
currently required by the driver.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
clock architecture requiring only two clocks to be referenced.
The IP is slightly different compared to i.MX 6, but currently none
of this differences are in use, therefore reuse GPMI_IS_MX6.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Add device specific list of clocks required, and handle all clocks
in a single for loop. This avoids further code duplication when
adding i.MX 7 support.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

If we see ~0UL in flash, there's no need for hweight, and no need to
check number of bitflips. So this should be net win.
Signed-off-by: NPavel Machek <pavel@denx.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This commit adjusts the fsmc_nand driver so that it accepts the
NAND_ECC_ON_DIE case. It simply does nothing in this case, since both
the ECC operations and OOB layout will be defined by the NAND chip code
rather than by the NAND controller code.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

Now that the core NAND subsystem has support for on-die ECC, this commit
brings the necessary code to support on-die ECC on Micron NANDs.

In micron_nand_init(), we detect if the Micron NAND chip supports on-die
ECC mode, by checking a number of conditions:

 - It must be an ONFI NAND
 - It must be a SLC NAND

 - Enabling *and* disabling on-die ECC must work

 - The on-die ECC must be correcting 4 bits per 512 bytes of data. Some
   Micron NAND chips have an on-die ECC able to correct 8 bits per 512
   bytes of data, but they work slightly differently and therefore we
   don't support them in this patch.

Then, if the on-die ECC cannot be disabled (some Micron NAND have on-die
ECC forcefully enabled), we bail out, as we don't support such
NANDs. Indeed, the implementation of raw_read()/raw_write() make the
assumption that on-die ECC can be disabled. Support for Micron NANDs
with on-die ECC forcefully enabled can easily be added, but in the
absence of such HW for testing, we preferred to simply bail out.

If the on-die ECC is supported, and requested in the Device Tree, then
it is indeed enabled, by using custom implementations of the
->read_page(), ->read_page_raw(), ->write_page() and ->write_page_raw()
operation to properly handle the on-die ECC.

In the non-raw functions, we need to enable the internal ECC engine
before issuing the NAND_CMD_READ0 or NAND_CMD_SEQIN commands, which is
why we set the NAND_ECC_CUSTOM_PAGE_ACCESS option at initialization
time (it asks the NAND core to let the NAND driver issue those
commands).
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

A lot of drivers are providing their own ->cmdfunc(), and most of the
time this implementation does not support all possible NAND operations.
But since ->cmdfunc() cannot return an error code, the core has no way
to know that the operation it requested is not supported.

This is a problem we cannot address for all kind of operations with the
current design, but we can prevent these silent failures for the
GET/SET FEATURES operation by overloading the default
->onfi_{set,get}_features() methods with one returning -ENOTSUPP.
Reported-by: NChris Packham <Chris.Packham@alliedtelesis.co.nz>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Tested-by: NChris Packham <Chris.Packham@alliedtelesis.co.nz>

The nand_read_page_raw() and nand_write_page_raw() functions might be
re-used by vendor-specific implementations of the read_page/write_page
functions. Instead of having vendor-specific code duplicate this code,
it is much better to export those functions and allow them to be
re-used.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

A number of NAND flashes have a capability called "on-die ECC" where the
NAND chip itself is capable of detecting and correcting errors.

Linux already has support for using the ECC implementation of the NAND
controller, or a software based ECC implementation, but not for using
the ECC implementation of the NAND controller. However, such an
implementation is sometimes useful in situations where the NAND
controller provides ECC algorithms that are not strong enough for the
NAND chip used on the system. A typical case is a NAND chip that
requires a 4-bit ECC, while the NAND controller only provides a 1-bit
ECC algorithm.

This commit introduces the support for the NAND_ECC_ON_DIE ECC mode:

 - Parsing of the "on-die" value for the "nand-ecc-mode" Device Tree
   property

 - Handling NAND_ECC_ON_DIE case in nand_scan_tail(). The idea is that
   the vendor specific code for the NAND chip must implement
   ->read_page() and ->write_page(). It may optionally provide its own
   ->read_page_raw() and ->write_page_raw() as well. For OOB operation,
   we assume the standard operations are good enough, but they can be
   overridden by the vendor specific code if needed.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>