- 20 Jun, 2017 1 commit
-
-
Masahiro Yamada authored
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:Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
- 13 Jun, 2017 1 commit
-
-
Alexandre Belloni authored
The Atmel NAND driver doesn't used anything from linux/platform_data/atmel.h, stop including it. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
- 10 Jun, 2017 11 commits
-
-
Masahiro Yamada authored
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Masahiro Yamada authored
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: -
Masahiro Yamada authored
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 authored
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: -
Masahiro Yamada authored
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: -
Masahiro Yamada authored
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:
-
Masahiro Yamada authored
No need to use two struct resource pointers. Just reuse one. Signed-off-by:
-
Matthias Lange authored
Signed-off-by:
Matthias Lange <matthias.lange@kernkonzept.com> Signed-off-by:
-
Matthias Lange authored
This makes it easier to grep. Signed-off-by:
-
Arvind Yadav authored
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Boris Brezillon authored
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:
Pavel Machek <pavel@denx.de> Reported-by:
Darwin Dingel <Darwin.Dingel@alliedtelesis.co.nz> Acked-by:
-
- 01 Jun, 2017 24 commits
-
-
Xiaolei Li authored
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:Xiaolei Li <xiaolei.li@mediatek.com> Signed-off-by:
-
Xiaolei Li authored
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:
-
Xiaolei Li authored
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:
-
Xiaolei Li authored
Add MT2712 NAND Flash Controller dt bindings documentation. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
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:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Masahiro Yamada authored
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: -
Boris Brezillon authored
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:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
Boris Brezillon authored
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: -
Boris Brezillon authored
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:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
-
Boris Brezillon authored
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: -
Boris Brezillon authored
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: -
Boris Brezillon authored
The ->errstat() hook is no longer implemented NAND controller drivers. Get rid of it before someone starts abusing it. Signed-off-by: -
Boris Brezillon authored
Cached programming is always skipped, so drop the associated code until we decide to really support it. Signed-off-by: -
Boris Brezillon authored
Provide a ->resume() hook to make sure the NAND timings are correctly restored by resetting all chips connected to the controller. Signed-off-by: -
Boris Brezillon authored
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: -
Boris Brezillon authored
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: -
Boris Brezillon authored
The only user of gpmi_nand_exit() is gpmi_nand_remove(). Move its content to the caller. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Acked-by:
Han Xu <han.xu@nxp.com>
-
Boris Brezillon authored
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:
-
Stefan Agner authored
The clock requirements are completely missing, add the clocks currently required by the driver. Signed-off-by:
Stefan Agner <stefan@agner.ch> Acked-by:
-
Stefan Agner authored
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:
-
Stefan Agner authored
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:
-
Pavel Machek authored
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:
-
Thomas Petazzoni authored
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:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Thomas Petazzoni authored
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:
-
- 30 May, 2017 1 commit
-
-
Boris Brezillon authored
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:Chris Packham <Chris.Packham@alliedtelesis.co.nz> Signed-off-by:
-
- 15 May, 2017 2 commits
-
-
Thomas Petazzoni authored
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:
-
Thomas Petazzoni authored
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:
-
