- 25 Apr, 2017 20 commits
-
-
Sekhar Nori authored
Add a comment clarifying that NAND subpage write on keystone works, but is not being enabled in the interest of backward compatibility. Signed-off-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
Roger Quadros authored
commit c9711ec5 ("mtd: nand: omap: Clean up device tree support") caused the parent device name to be changed from "omap2-nand.0" to "<base address>.nand" (e.g. 30000000.nand on omap3 platforms). This caused mtd->name to be changed as well. This breaks partition creation via mtdparts passed by u-boot as it uses "omap2-nand.0" for the mtd-id. Fix this by explicitly setting the mtd->name to "omap2-nand.<CS number>" if it isn't already set by nand_set_flash_node(). CS number is the NAND controller instance ID. Fixes: c9711ec5 ("mtd: nand: omap: Clean up device tree support") Cc: <stable@vger.kernel.org> # 4.7+ Reported-by:
Leto Enrico <enrico.leto@siemens.com> Reported-by:
Adam Ford <aford173@gmail.com> Suggested-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Christophe Jaillet authored
of_device_id tables should be NULL terminated. Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Dan Carpenter authored
We accidentally return 1 on error instead of proper error codes. Fixes: 07b23e3db9ed ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Masahiro Yamada authored
In some cases, nand_do_{read,write}_ops is passed with unaligned ops->datbuf. Drivers using DMA will be unhappy about unaligned buffer. The new struct member, buf_align, represents the minimum alignment the driver require for the buffer. If the buffer passed from the upper MTD layer does not have enough alignment, nand_do_*_ops will use bufpoi. Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Masahiro Yamada authored
Some NAND controllers are using DMA engine requiring a specific buffer alignment. The core provides no guarantee on the nand_buffers pointers, which forces some drivers to allocate their own buffers and pass the NAND_OWN_BUFFERS flag. Rework the nand_buffers allocation logic to allocate each buffer independently. This should make most NAND controllers/DMA engine happy, and allow us to get rid of these custom buf allocation in NAND controller drivers. Signed-off-by:
-
Masahiro Yamada authored
Commit 271707b1 ("mtd: nand: denali: max_banks calculation changed in revision 5.1") added a revision check to support the new max_banks encoding. Its git-log states "The encoding of max_banks changed in Denali revision 5.1". There are exceptional cases, for example, the revision register on some UniPhier SoCs says the IP is 5.0 but the max_banks is encoded in the new format. This IP updates the resister specification from time to time (often breaking the backward compatibility), but the revision number is not incremented correctly. The max_banks is not only the case that needs revision checking. Let's allow to override an incorrect revision number. Signed-off-by:
-
Masahiro Yamada authored
"pdev" is much more often used to point a platform_device, so this will help the driver code look consistent across the kernel. While we are here, fix "line over 80 characters" coding style violations. Signed-off-by:
-
Masahiro Yamada authored
The driver sets appropriate DMA mask. Delete the "dma-mask" DT property. See [1] for negative comments for this binding. [1] https://lkml.org/lkml/2016/2/8/57Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Masahiro Yamada authored
The current driver only supports the DMA engine up to 32 bit physical address, but there also exists 64 bit capable DMA engine for this IP. The data DMA setup sequence is completely different, so I added the 64 bit DMA code as a new function denali_setup_dma64(). The 32 bit one has been renamed to denali_setup_dma32(). Signed-off-by:
-
Masahiro Yamada authored
There are various customizable parameters, so several variants for this IP. A generic compatible like "denali,denali-nand-dt" is useless. Moreover, there are multiple things wrong with this string. (Refer to Rob's comment [1]) The "denali,denali-nand-dt" was added by Altera for the SOCFPGA port. Replace it with a more specific string "altr,socfpga-denali-nand". There are no users (in upstream) of the old compatible string. The Denali IP on SOCFPGA incorporates the hardware ECC fixup engine. So, this capability should be associated with the compatible. [1] https://lkml.org/lkml/2016/12/1/450Signed-off-by:
-
Masahiro Yamada authored
Some old versions of the Denali IP (perhaps used only for Intel?) detects ECC errors and provides correct data via a register, but does not touch the transferred data. So, the software must fixup the data in the buffer according to the provided ECC correction information. Newer versions perform ECC correction before transferring the data. No more software intervention is needed. The ECC_ERROR_ADDRESS and ECC_CORRECTION_INFO registers were deprecated. Instead, the number of corrected bit-flips are reported via the ECC_COR_INFO register. When an uncorrectable ECC error happens, a status flag is set to the INTR_STATUS and ECC_COR_INFO registers. As is often the case with this IP, the register view of INTR_STATUS had broken compatibility. For older versions (SW ECC fixup): bit 0: ECC_TRANSACTION_DONE bit 1: ECC_ERR For newer versions (HW ECC fixup): bit 0: ECC_UNCOR_ERR bit 1: Reserved Due to this difference, the irq_mask must be fixed too. The existing handle_ecc() has been renamed to denali_sw_ecc_fixup() for clarification. What is unfortunate with this feature is we can not know the total number of corrected/uncorrected errors in a page. The register ECC_COR_INFO reports the maximum of per-sector bitflips. This is useful for ->read_page return value, but ecc_stats.{corrected,failed} increments may not be precise. Signed-off-by: -
Masahiro Yamada authored
This part is wrong in multiple ways: [1] is_erased() is called against "buf" twice, so the OOB area is not checked at all. The second call should check chip->oob_poi. [2] This code block is nested by double "if (check_erase_page)". The inner one is redundant. [3] The ECC_ERROR_ADDRESS register reports which sector(s) had uncorrectable ECC errors. It is pointless to check the whole page if only one sector contains errors. [4] Unfortunately, the Denali ECC correction engine has already manipulated the data buffer before it decides the bitflips are uncorrectable. That is, not all of the data are 0xFF after an erased page is processed by the ECC engine. The current is_erased() helper could report false-positive ECC errors. Actually, a certain mount of bitflips are allowed in an erased page. The core framework provides nand_check_erased_ecc_chunk() that takes the threshold into account. Let's use this. This commit reworks the code to solve those problems. Please note the erased page checking is implemented as a separate helper function instead of embedding it in the loop in handle_ecc(). The reason is that OOB data are needed for the erased page checking, but the controller can not start a new transaction until all ECC error information is read out from the registers. Signed-off-by:
-
Masahiro Yamada authored
This function is wrong in multiple ways: [1] Counting corrected bytes instead of corrected bits. The following code is counting the number of corrected _bytes_. /* correct the ECC error */ buf[offset] ^= err_cor_value; mtd->ecc_stats.corrected++; bitflips++; What the core framework expects is the number of corrected _bits_. They can be different if multiple bitflips occur within one byte. [2] total number of errors instead of max of per-sector errors The core framework expects that corrected errors are counted per sector, then the max value should be taken. The current code simply iterates over the whole page, i.e. counts the total number of correction in the page. This means "too many bitflips" is triggered earlier than it should be, i.e. the NAND device is worn out sooner. Besides those bugs, this function is unreadable due to the deep nesting. Notice the whole code in this function is wrapped in if (irq_status & INTR__ECC_ERR), so this conditional can be moved out of the function. Also, use shorter names for local variables. Re-work the function to fix all the issues. Signed-off-by: -
Masahiro Yamada authored
The pipeline read-ahead function of the Denali IP enables continuous reading from the device; while data is being read out by a CPU, the controller maintains additional commands for streaming data from the device. This will reduce the latency of the second page or later. This feature is obviously no help for per-page accessors of Linux NAND driver interface. In the current implementation, the pipeline command is issued to load a single page, then data are read out immediately. The use of the pipeline operation is not adding any advantage, but just adding complexity to the code. Remove. Signed-off-by:
-
Masahiro Yamada authored
Commit 28309572 ("mtd: name the mtd device with an optional label property") allow us to identify a chip in a user-friendly way. If nand_set_flash_node() picks up the "label" from DT, let's respect it. Otherwise, let it fallback to the current name "denali-nand". Signed-off-by:
-
Masahiro Yamada authored
The comment for ecc.read_page() requires that it should return "0 if bitflips uncorrectable". Actually, drivers could return positive values when uncorrectable bitflips occur. For example, nand_read_page_swecc() is the case. If ecc.correct() returns -EBADMSG for the first ECC sector, and a positive value for the second one, nand_read_page_swecc() returns a positive max_bitflips and increments ecc_stats.failed for the same page. The requirement can be relaxed by tweaking nand_do_read_ops(). Move the max_bitflips calculation below the retry. Signed-off-by:
-
Boris Brezillon authored
The last/only user of the chip->write_page() hook (the Atmel NAND controller driver) has been reworked and is no longer specifying a custom ->write_page() implementation. Drop this hook before someone else start abusing it. Signed-off-by:
-
Boris Brezillon authored
The old NAND bindings were not exactly describing the hardware topology and were preventing definitions of several NAND chips under the same NAND controller. New bindings address these limitations and should be preferred over the old ones for new SoCs/boards. Old bindings are still supported for backward compatibility but are marked deprecated in the doc. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by:
-
Boris Brezillon authored
This is a complete rewrite of the driver whose main purpose is to support the new DT representation where the NAND controller node is now really visible in the DT and appears under the EBI bus. With this new representation, we can add other devices under the EBI bus without risking pinmuxing conflicts (the NAND controller is under the EBI bus logic and as such, share some of its pins with other devices connected on this bus). Even though the goal of this rework was not necessarily to add new features, the new driver has been designed with this in mind. With a clearer separation between the different blocks and different IP revisions, adding new functionalities should be easier (we already have plans to support SMC timing configuration so that we no longer have to rely on the configuration done by the bootloader/bootstrap). Also note that we no longer have a custom ->cmdfunc() implementation, which means we can now benefit from new features added in the core implementation for free (support for new NAND operations for example). The last thing that we gain with this rework is support for multi-chips and multi-dies chips, thanks to the clean NAND controller <-> NAND devices representation. During this transition we also dropped support for AVR32 SoCs which should soon disappear from mainline (removal of the AVR32 arch is planned for 4.12). This new driver has been tested on several platforms (at91sam9261, at91sam9g45, at91sam9x5, sama5d3 and sama5d4) to make sure it did not introduce regressions, and it's worth mentioning that old bindings are still supported (which partly explain the positive diffstat). Signed-off-by:
-
- 29 Mar, 2017 2 commits
-
-
Simon Baatz authored
The clock gate used by orion_nand is not available on all platforms. When getting this optional clock gate, the code masked all errors. Let's be more precise here and actually only allow ENOENT. EPROBE_DEFER is handled like any other error code since probe deferral is not supported by drivers using module_platform_driver_probe(). Signed-off-by:
Simon Baatz <gmbnomis@gmail.com> Signed-off-by:
-
Simon Baatz authored
The clk handling in orion_nand.c had two problems: - In the probe function, clk_put() was called for an enabled clock, which violates the API (see documentation for clk_put() in include/linux/clk.h) - In the error path of the probe function, clk_put() could be called twice for the same clock. In order to clean this up, use the managed function devm_clk_get() and store the pointer to the clk in the driver data. Fixes: baffab28 ('ARM: Orion: fix driver probe error handling with respect to clk') Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
-
- 28 Mar, 2017 4 commits
-
-
Masahiro Yamada authored
Because SUPPORT_15BITECC is defined, the following is dead code: #elif SUPPORT_8BITECC iowrite32(8, denali->flash_reg + ECC_CORRECTION); #endif Such ifdefs are useless and unacceptable coding style. These writes are not needed in the first place since ECC_CORRECTION is set up by the nand_init() function. Signed-off-by: -
Masahiro Yamada authored
The write accesses to LOGICAL_PAGE_{DATA,SPARE}_SIZE have no effect because the Denali User's Guide says these registers are read-only. The hardware automatically multiplies the main/spare size by the number of devices and update LOGICAL_PAGE_{DATA,SPARE}_SIZE. Signed-off-by: -
Masahiro Yamada authored
Currently, the driver expects DEVICE_CONNECTED is automatically set by the hardware, but this feature is disabled in some cases. In such cases, it is the software's responsibility to set up the DEVICES_CONNECTED register. Signed-off-by:
-
Masahiro Yamada authored
The available configuration of the IP bus width is x8 or x16, so the possible value for denali->devnum is 1 or 2. If the value is 1, there is nothing to do. Fixup parameters only when denali->devnum is 2. Signed-off-by:
-
- 27 Mar, 2017 3 commits
-
-
Masahiro Yamada authored
Collect multi NAND fixups into a helper function instead of scattering them in denali_init(). I am rewording the comment block to clearly explain what is called "multi device". Signed-off-by:
-
Masahiro Yamada authored
This will allow nand_dt_init() to parse DT properties in the NAND controller device node. Signed-off-by:
-
Masahiro Yamada authored
The denali_init() needs to setup a bunch of parameters of nand_chip. Replace denali->nand.(member) with chip->(member) for shorter code. Signed-off-by:
-
- 24 Mar, 2017 11 commits
-
-
Masahiro Yamada authored
Set Features (0xEF) command toggles the R/B# pin after 4 sub feature parameters are written. Currently, nand_command(_lp) calls chip->dev_ready immediately after the address cycle because NAND_CMD_SET_FEATURES falls into default: label. No wait is needed at this point. If you see nand_onfi_set_features(), R/B# is already cared by the chip->waitfunc call. Signed-off-by:
-
Masahiro Yamada authored
Read ID (0x90) command does not toggle the R/B# pin. Without this patch, NAND_CMD_READID falls into the default: label, then R/B# is checked by chip->dev_ready(). Signed-off-by:
-
Masahiro Yamada authored
The page number is generally stored in an integer type variable. The uint16_t does not have enough width. I see no reason to use uint32_t for other members, either. Just use int. Signed-off-by:
-
Masahiro Yamada authored
The Denali NAND controller IP has various customizable features. SoC vendors can choose desired functions when a delivery RTL is created. It means there are several variants for this IP. For example, the Intel version is equipped with 32bit DMA, whereas the IP for UniPhier SoC family with 64bit DMA. This driver was originally written for some Intel platforms with Intel specific things hard-coded. What is worse, the revision register of this IP does not work to distinguish such features. We need to do something to make the driver available for other SoCs. Let's introduce a caps member to the denali_nand_info structure to switch on/off various features. Also, add struct denali_dt_data to store the capability associated with compatible string. Boris suggested this approach in discussion [1] instead of a new DT property for every feature. [1] https://lkml.org/lkml/2016/3/29/142Signed-off-by:
-
Masahiro Yamada authored
The interrupts are enabled by INTR_EN register, then asserted interrupts can be observed via INTR_STATUS register. The bit fields are identical between INTR_EN and INTR_STATUS, so we can merge the bit field macros. Likewise for DATA_INTR. Signed-off-by:
-
Masahiro Yamada authored
The same comment "Mapped io reg base address" for flash_reg and flash_mem probably due to the mistake of copy-paste work. Of course, the latter is not the register base address. Reword the comments using the terminology in the Denali User's Guide. Signed-off-by:
-
Masahiro Yamada authored
These members are not used at all. Signed-off-by:
-
Masahiro Yamada authored
This macro is defined twice in denali.c (around line 98 and line 651), so remove the second one. Signed-off-by:
-
Masahiro Yamada authored
All of these macros are not used at all. CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR is not used for anything but defining SCRATCH_REG_ADDR. The config option should go away as well. I am removing some register macros. They are not used, and do not exist in recent IP versions. Signed-off-by:
-
Masahiro Yamada authored
The nand_default_block_markbad() and scan_block_fast() use high level APIs to get access to the BBM. On the other hand, nand_block_bad (the default implementation of ->block_bad) calls the lower level ->cmdfunc hook. This prevents drivers from using ->ecc.read_oob() even if optimized read operation is implemented. Besides, some NAND controllers may protect the BBM with ECC. Signed-off-by:
-
Masahiro Yamada authored
Currently, it is valid to specify both "nand-ecc-step-size" and "nand-ecc-strength", but not allowed to set only one of them. This requirement has a conflict with "nand-ecc-maximize"; this flag is used when you want the driver to choose the best ECC strength. If "nand-ecc-maximize" is set, "nand-ecc-strength" is very likely to be unset. It would be possible to make the if-conditional more complex by adding the check for the NAND_ECC_MAXIMIZE flag, but I chose to drop the check entirely. I thought of the situation where the hardware has a fixed ECC step size (so it can be hard-coded in the driver), whereas the ECC strength is configurable by software. In that case, we may want to only set "nand-ecc-strength" (or "nand-ecc-maximize") in DT. Signed-off-by:
-
