- 18 Apr, 2019 40 commits
-
-
Richard Weinberger authored
Stop using the legacy interface. Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com>
-
Richard Weinberger authored
We will need struct nand_controller soon, so more stuff need to be parts of struct nandsim. While we are here, rename "nand" to "ns" to use the same naming scheme everywhere in nandsim. Reviewed-by:
-
Frieder Schrempf authored
According to the datasheet of some Cypress SLC NANDs, the bad block markers can be in the first, second or last page of a block. So let's check all three locations. Signed-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Boris Brezillon <bbrezillon@kernel.org> Reviewed-by:
-
Frieder Schrempf authored
It is known that some ESMT SLC NANDs have been shipped with the factory bad block markers in the first or last page of the block, instead of the first or second page. To be on the safe side, let's check all three locations. Signed-off-by:
-
Frieder Schrempf authored
Currently supported bad block marker positions within the block are: * in first page only * in last page only * in first or second page Some ESMT NANDs are known to have been shipped by the manufacturer with bad block markers in the first or last page, instead of the first or second page. Also the datasheets for Cypress/Spansion/AMD NANDs claim that the first, second *and* last page needs to be checked. Therefore we make it possible to set NAND_BBM_FIRSTPAGE, NAND_BBM_SECONDPAGE and NAND_BBM_LASTPAGE independently in any combination. To simplify the code, the logic to evaluate the flags is moved to a a new function nand_bbm_get_next_page(). Signed-off-by:
-
Frieder Schrempf authored
To be able to check and set bad block markers in the first and second page of a block independently of each other, we create separate flags for both cases. Previously NAND_BBM_SECONDPAGE meant, that both, the first and the second page were used. With this patch NAND_BBM_FIRSTPAGE stands for using the first page and NAND_BBM_SECONDPAGE for using the second page. This patch is only for preparation of subsequent changes and does not implement the logic to actually handle both flags separately. Signed-off-by:
-
Frieder Schrempf authored
Now that we have moved the information to the chip level, let's remove all the unused flags and fields. Signed-off-by:
-
Frieder Schrempf authored
The information about where the manufacturer puts the bad block markers inside the bad block and in the OOB data is stored in different places. Let's move this information to the chip struct, as we did it for rawnand. Signed-off-by:
-
Frieder Schrempf authored
The information about where the manufacturer puts the bad block markers inside the bad block and in the OOB data is stored in different places. Let's move this information to nand_chip.options and nand_chip.badblockpos. As this chip-specific information is not directly related to the bad block table (BBT), we also rename the flags to NAND_BBM_*. Signed-off-by:
-
Martin Blumenstingl authored
Documentation/scheduler/completion.txt states: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. Initialize nfc->completion in meson_nfc_probe using init_completion and change the call in meson_nfc_queue_rb to reinit_completion so the logic matches what the documentation suggests. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by:
Liang Yang <liang.yang@amlogic.com> Acked-by:
-
Martin Blumenstingl authored
This simplifies the code because it gets rid of the casts to an u8-pointer when passing "info_buf" from struct meson_nfc_nand_chip. Also it gets rid of the cast of the u8 databuf pointer to a void pointer. The logic inside meson_nfc_dma_buffer_setup() doesn't care about the pointer types themselves because it only passes them to dma_map_single which accepts a void pointer. No functional changes. Signed-off-by:
-
Martin Blumenstingl authored
Use the of_property_count_elems_of_size() helper instead of open-coding it's logic. As a bonus this will now error out if the "reg" property values use an incorrect size (anything other than sizeof(u32)). Signed-off-by:
-
Martin Blumenstingl authored
Use the recently introduced struct_size macro instead of open-coding it's logic. No functional changes. Signed-off-by:
-
Masahiro Yamada authored
Currently, drivers are able to constify a nand_op_parser array, but not nand_op_parser_pattern and nand_op_parser_pattern_elem since they are instantiated by using the NAND_OP_PARSER(_PATTERN). Add 'const' to them in order to move more driver data from .data to .rodata section. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
-
Miquel Raynal authored
Since the migration of the driver to stop using the legacy ->select_chip() hook, the marvell_nfc_select_chip() helper has been 'renamed' to marvell_nfc_select_target(). Update a left-over reference to this helper in a comment in the ->resume() path. Fixes: b2525141 ("mtd: rawnand: marvell: Stop implementing ->select_chip()") Signed-off-by:
-
Miquel Raynal authored
Allwinner NAND controllers can make use of DMA to enhance the I/O throughput thanks to ECC pipelining. DMA handling with A23/A33 NAND IP is a bit different than with the older SoCs, hence the introduction of a new compatible to handle: * the differences between register offsets, * the burst length change from 4 to minimum 8, * drive SRAM accesses through the AHB bus instead of the MBUS. Signed-off-by: -
Miquel Raynal authored
Before the introduction of A33 NAND DMA support, let's use a platform data structure for parameters that will differ. Right now, there is only one compatible with one data structure. Signed-off-by: -
Miquel Raynal authored
The A23/A33 NAND controller is slightly different than the A10+ ones, eg. DMA handling is a bit different and a few register offsets changed. Introduce a new compatible to represent this version of the IP. Also append '-controller' to the new compatible (which is required for new compatibles) as this is describing a NAND controller and not a NAND chip. Signed-off-by: -
Maxime Ripard authored
Switch the DT binding to a YAML schema to enable the DT validation. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Maxime Ripard authored
The NAND chips in MTD have a bunch of generic options that are needed in a device tree. Add a YAML schemas for those. Signed-off-by:
-
YueHaibing authored
Fix sparse warning: drivers/mtd/nand/raw/ingenic/ingenic_nand.c:140:32: warning: symbol 'jz4725b_ooblayout_ops' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
gcc warning this: WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/raw/ingenic/ingenic_ecc.o Add MODULE_LICENSE,MODULE_AUTHOR and MODULE_DESCRIPTION. Reported-by:
-
Masahiro Yamada authored
Eliminate the following reports from 'scripts/checkpatch.pl --strict'. CHECK: Prefer kernel type 'u8' over 'uint8_t' CHECK: Prefer kernel type 'u32' over 'uint32_t' CHECK: Alignment should match open parenthesis I slightly changed denali_check_erased_page() to shorten it. Signed-off-by:
-
Masahiro Yamada authored
Use the runtime-detected denali->nbanks instead of hard-coded DENALI_NR_BANKS (=4). The actual number of banks depends on the IP configuration, and can be less than DENALI_NR_BANKS. It is pointless to touch registers of unsupported banks. Signed-off-by:
-
Masahiro Yamada authored
Currently, this driver sticks to the legacy NAND model because it was upstreamed before commit 2d472aba ("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 authored
As Documentation/process/coding-style.rst says, choose label names which say what the goto does. The out_<action> label style is already used in denali_dt.c. Rename likewise for denali_pci.c Signed-off-by:
-
Masahiro Yamada authored
Use 'bool' type for the following boolean parameters. - write (write or read?) - dma_avail (DMA engine available or not?) Signed-off-by:
-
Masahiro Yamada authored
Implement ->exec_op(), and remove the deprecated hooks. Signed-off-by:
-
Masahiro Yamada authored
Since (u32 *) can accept an opaque pointer, the explicit casting from (void *) to (u32 *) is redundant. Change the function argument type to remove the casts. Signed-off-by:
-
Masahiro Yamada authored
The Denali IP adopts the syndrome page layout (payload and ECC are interleaved). The *_page_raw() and *_oob() callbacks are complicated because they must hide the underlying layout used by the hardware, and always return contiguous in-band and out-of-band data. The Denali IP cannot reuse nand_{read,write}_page_raw_syndrome() in nand_base.c because its hardware ECC engine skips some of first bytes in OOB. That is why this driver implements specially-crafted *_page_raw() and *_oob() hooks. Currently, similar code is duplicated to reorganize the data layout. For example, denali_read_page_raw() and denali_write_page_raw() look almost the same. The complexity is partly due to the DMA transfer used for better performance of *_page_raw() accessors. On second thought, we do not need to care about their performance because MTD_OPS_RAW is rarely used. Let's focus on code cleanups rather than the performance. This commit removes the internal buffer for DMA, and factors out as much code as possible. Signed-off-by: -
Masahiro Yamada authored
With the recent refactoring, the NAND driver hooks now take a pointer to nand_chip. Add to_denali() in order to convert (struct nand_chip *) to (struct denali_nand_info *) directly. It is more useful than the current mtd_to_denali(). I changed some helper functions to take (struct nand_chip *). This will avoid pointer conversion back and forth, and ease further development. Signed-off-by:
-
Miquel Raynal authored
Wrong copy/paste from the previous block, the error message should refer to #size-cells instead of #address-cells. Fixes: f88fc122 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com>
-
Marek Behún authored
Move the code that choses ECC into _attach_chip, which is executed only after the chip->ecc.* properties were loaded from device-tree. This way we know which ECC method was chosen by the device-tree and can set methods appropriately. The chip->ecc.*page methods should be set to fsl_elbc_*page only in HW ECC mode. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Signed-off-by:
-
Marek Behún authored
This is needed for SW ECC. Signed-off-by:
-
Marek Behún authored
Move the fsl_elbc_attach_chip function after the definitions of fsl_elbc_read_page and friends in preparation for the next patch. Signed-off-by:
-
Jonathan Neuschäfer authored
Sphinx doesn't handle expressions in identifier references. This fixes the following warnings: ./include/linux/mtd/rawnand.h:1184: WARNING: Inline strong start-string without end-string. ./include/linux/mtd/rawnand.h:1186: WARNING: Inline strong start-string without end-string. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Anders Roxell authored
When enabling CONFIG_MTD_NAND_ECC_SW_BCH as a module, the MTD_NAND_ECC_SW_BCH depends on MTD_NAND, but the module controlled by MTD_NAND links against the module controlled by MTD_NAND_ECC_SW_BCH. This leads to the following link failure. aarch64-linux-gnu-ld: drivers/mtd/nand/raw/nand_base.o: in function `nand_cleanup': ../drivers/mtd/nand/raw/nand_base.c:5886: undefined reference to `nand_bch_free' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5886:(.text+0x9928): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `nand_bch_free' aarch64-linux-gnu-ld: drivers/mtd/nand/raw/nand_base.o: in function `nand_set_ecc_soft_ops': ../drivers/mtd/nand/raw/nand_base.c:5093: undefined reference to `nand_bch_calculate_ecc' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5093:(.text+0xe914): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `nand_bch_calculate_ecc' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5093: undefined reference to `nand_bch_calculate_ecc' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5094: undefined reference to `nand_bch_correct_data' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5094:(.text+0xe934): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21 against undefined symbol `nand_bch_correct_data' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5094: undefined reference to `nand_bch_correct_data' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5148: undefined reference to `nand_bch_init' aarch64-linux-gnu-ld: ../drivers/mtd/nand/raw/nand_base.c:5148:(.text+0xebbc): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `nand_bch_init' Rework CONFIG_MTD_NAND_ECC_SW_BCH from tristate to bool, and then link the nand_bch.o file into nand.ko if its enabled. Fixes: 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm") Signed-off-by:Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
-
Miquel Raynal authored
Prepare changes that will lay in this file to better express what is NAND related and what is not in menuconfig. Signed-off-by: -
Miquel Raynal authored
MTD_NAND is large and encloses much more than what the symbol is actually used for: raw NAND. Clarify the symbol by naming it MTD_RAW_NAND instead. Signed-off-by: -
Miquel Raynal authored
This list is a mess, while some items should probably not be in the raw/ sub-directory, others are definitely at the right place but not with the right description. Write uniform titles and group IPs by vendor. NAND controllers will appear under the list named "Raw/parallel NAND flash controllers" while the other drivers will appear under "Misc". Software ECC engines will later be moved out of the raw/ directory. Signed-off-by:
-
