- 10 Dec, 2020 40 commits
-
-
Yifeng Zhao authored
Documentation support for Rockchip RK3xxx NAND flash controllers Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Yifeng Zhao <yifeng.zhao@rock-chips.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201210002134.5686-2-yifeng.zhao@rock-chips.com
-
Fabio Estevam authored
The .compatible and .data pairs can be stored in a single line, which makes the code more concise. Signed-off-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
Han Xu authored
To get better performance, current gpmi driver collected and chained all small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end. But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows: Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below, 63.216351 | 1) | gpmi_ecc_read_page() { 63.216352 | 1) 0.750 us | gpmi_bch_layout_std(); 63.216354 | 1) | gpmi_nfc_exec_op() { 63.216355 | 1) | gpmi_chain_command() { 63.216356 | 1) | mxs_dma_prep_slave_sg() { 63.216357 | 1) | /* mxs chan ccw idx: 0 */ 63.216358 | 1) 1.750 us | } 63.216359 | 1) | mxs_dma_prep_slave_sg() { 63.216360 | 1) | /* mxs chan ccw idx: 1 */ 63.216361 | 1) 2.000 us | } 63.216361 | 1) 6.500 us | } 63.216362 | 1) | gpmi_chain_command() { 63.216363 | 1) | mxs_dma_prep_slave_sg() { 63.216364 | 1) | /* mxs chan ccw idx: 2 */ 63.216365 | 1) 1.750 us | } 63.216366 | 1) | mxs_dma_prep_slave_sg() { 63.216367 | 1) | /* mxs chan ccw idx: 3 */ 63.216367 | 1) 1.750 us | } 63.216368 | 1) 5.875 us | } 63.216369 | 1) | /* gpmi_chain_wait_ready */ 63.216370 | 1) | mxs_dma_prep_slave_sg() { 63.216372 | 1) | /* mxs chan ccw idx: 4 */ 63.216373 | 1) 3.000 us | } 63.216374 | 1) | /* gpmi_chain_data_read */ 63.216376 | 1) | mxs_dma_prep_slave_sg() { 63.216377 | 1) | /* mxs chan ccw idx: 5 */ 63.216378 | 1) 2.000 us | } 63.216379 | 1) 1.125 us | mxs_dma_tx_submit(); 63.216381 | 1) 1.000 us | mxs_dma_enable_chan(); 63.216712 | 0) 2.625 us | mxs_dma_int_handler(); 63.216717 | 0) 4.250 us | bch_irq(); 63.216723 | 0) 1.250 us | mxs_dma_tasklet(); 63.216723 | 1) | /* jiffies left 250 */ 63.216725 | 1) ! 372.000 us | } 63.216726 | 1) 2.625 us | gpmi_count_bitflips(); 63.216730 | 1) ! 379.125 us | } but it's not gurantee that bch irq handled always after dma irq handled, sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore, another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened. 63.218923 | 1) | gpmi_ecc_read_page() { 63.218924 | 1) 0.625 us | gpmi_bch_layout_std(); 63.218926 | 1) | gpmi_nfc_exec_op() { 63.218927 | 1) | gpmi_chain_command() { 63.218928 | 1) | mxs_dma_prep_slave_sg() { 63.218929 | 1) | /* mxs chan ccw idx: 0 */ 63.218929 | 1) 1.625 us | } 63.218931 | 1) | mxs_dma_prep_slave_sg() { 63.218931 | 1) | /* mxs chan ccw idx: 1 */ 63.218932 | 1) 1.750 us | } 63.218933 | 1) 5.875 us | } 63.218934 | 1) | gpmi_chain_command() { 63.218934 | 1) | mxs_dma_prep_slave_sg() { 63.218935 | 1) | /* mxs chan ccw idx: 2 */ 63.218936 | 1) 1.875 us | } 63.218937 | 1) | mxs_dma_prep_slave_sg() { 63.218938 | 1) | /* mxs chan ccw idx: 3 */ 63.218939 | 1) 1.625 us | } 63.218939 | 1) 5.875 us | } 63.218940 | 1) | /* gpmi_chain_wait_ready */ 63.218941 | 1) | mxs_dma_prep_slave_sg() { 63.218942 | 1) | /* mxs chan ccw idx: 4 */ 63.218942 | 1) 1.625 us | } 63.218943 | 1) | /* gpmi_chain_data_read */ 63.218944 | 1) | mxs_dma_prep_slave_sg() { 63.218945 | 1) | /* mxs chan ccw idx: 5 */ 63.218947 | 1) 2.375 us | } 63.218948 | 1) 0.625 us | mxs_dma_tx_submit(); 63.218949 | 1) 1.000 us | mxs_dma_enable_chan(); 63.219276 | 0) 5.125 us | bch_irq(); <---- 63.219283 | 1) | /* jiffies left 250 */ 63.219285 | 1) ! 358.625 us | } 63.219286 | 1) 2.750 us | gpmi_count_bitflips(); 63.219289 | 1) ! 366.000 us | } 63.219290 | 1) | gpmi_ecc_read_page() { 63.219291 | 1) 0.750 us | gpmi_bch_layout_std(); 63.219293 | 1) | gpmi_nfc_exec_op() { 63.219294 | 1) | gpmi_chain_command() { 63.219295 | 1) | mxs_dma_prep_slave_sg() { 63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <---- 63.219296 | 1) | /* mxs chan ccw idx: 6 */ 63.219297 | 1) 2.250 us | } 63.219298 | 1) | mxs_dma_prep_slave_sg() { 63.219298 | 0) 1.000 us | mxs_dma_tasklet(); 63.219299 | 1) | /* mxs chan ccw idx: 0 */ 63.219300 | 1) 1.625 us | } 63.219300 | 1) 6.375 us | } 63.219301 | 1) | gpmi_chain_command() { 63.219302 | 1) | mxs_dma_prep_slave_sg() { 63.219303 | 1) | /* mxs chan ccw idx: 1 */ 63.219304 | 1) 1.625 us | } 63.219305 | 1) | mxs_dma_prep_slave_sg() { 63.219306 | 1) | /* mxs chan ccw idx: 2 */ 63.219306 | 1) 1.875 us | } 63.219307 | 1) 6.000 us | } 63.219308 | 1) | /* gpmi_chain_wait_ready */ 63.219308 | 1) | mxs_dma_prep_slave_sg() { 63.219309 | 1) | /* mxs chan ccw idx: 3 */ 63.219310 | 1) 2.000 us | } 63.219311 | 1) | /* gpmi_chain_data_read */ 63.219312 | 1) | mxs_dma_prep_slave_sg() { 63.219313 | 1) | /* mxs chan ccw idx: 4 */ 63.219314 | 1) 1.750 us | } 63.219315 | 1) 0.625 us | mxs_dma_tx_submit(); 63.219316 | 1) 0.875 us | mxs_dma_enable_chan(); 64.224227 | 1) | /* jiffies left 0 */ In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op exits, but DMA IRQ still not happened yet until the middle of following gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout. To fix the issue, when there is bch ops in DMA chain, the gpmi_nfc_exec_op should wait for both completions rather than bch completion only. Fixes: ef347c0c ("mtd: rawnand: gpmi: Implement exec_op") Signed-off-by:Han Xu <han.xu@nxp.com> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Han Xu authored
Set the GPMI CTRL1 GANGED_RDYBUSY bit so driver can sense the R/B signal from all CS. For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch. [ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01 After applying the patch [ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01 Signed-off-by:
-
Manivannan Sadhasivam authored
SDX55 uses QPIC version 2.0.0 IP for the NAND controller support. In this version, DEV_CMD_* registers are moved to operational state, hence CPU access in BAM mode is restricted. So, skip accessing these registers and also use a different config for reading ONFI parameters. Signed-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Manivannan Sadhasivam authored
Qualcomm SDX55 uses QPIC NAND controller version 2.0.0 with BAM DMA Engine. Signed-off-by:
-
Fabio Estevam authored
The .compatible and .data pairs can be stored in a single line, which makes the code more concise. Signed-off-by:
-
Fabio Estevam authored
The retrieval of driver data can be a bit simplified by using device_get_match_data(), so switch to it. Signed-off-by:
-
Dan Carpenter authored
Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function fails to avoid a resource leak. Fixes: 8fae856c ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Fabio Estevam authored
The retrieval of driver data via of_device_get_match_data() can make the code simpler. Use of_device_get_match_data() to simplify the code. Signed-off-by:
-
Ramuthevar Vadivel Murugan authored
This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. Signed-off-by:
Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> Signed-off-by:
-
Ramuthevar Vadivel Murugan authored
Add YAML file for dt-bindings to support NAND Flash Controller on Intel's Lightning Mountain SoC. Signed-off-by:
-
Thirumalesha Narasimhappa authored
The MT29F2G01AAAED is a single die, 2Gb Micron SPI NAND Flash with 4-bit ECC Signed-off-by:
Thirumalesha Narasimhappa <nthirumalesha7@gmail.com> Signed-off-by:
-
Thirumalesha Narasimhappa authored
Rename the read/write/update of SPINAND_OP_VARIANTS() to more specialized names. Signed-off-by:
-
Zhang Qilong authored
pm_runtime_get_sync() will increment pm usage at first and it will resume the device later. If runtime of the device has error or device is in inaccessible state(or other error state), resume operation will fail. If we do not call put operation to decrease the reference, it will result in reference leak in the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover, this device cannot enter the idle state and always stay busy or other non-idle state later. So we fixed it through adding pm_runtime_put_noidle. Fixes: 5bc6bb60 ("mtd: rawnand: gpmi: Fix suspend/resume problem") Signed-off-by:
Zhang Qilong <zhangqilong3@huawei.com> Acked-by:
-
Krzysztof Kozlowski authored
Driver requires different amount of clocks for different SoCs. Describe these requirements properly to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: nand-controller@33002000: clock-names:1: 'gpmi_apb' was expected Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by:
-
YouChing Lin authored
The Macronix MX35LF2GE4AD / MX35LF4GE4AD are 3V, 2G / 4Gbit serial SLC NAND flash device (with on-die ECC). Validated by read, erase, read back, write, read back and nandtest on Xilinx Zynq PicoZed FPGA board which included Macronix SPI Host (drivers/spi/spi-mxic.c). Signed-off-by:
YouChing Lin <ycllin@mxic.com.tw> Signed-off-by:
-
Baskov Evgeiny authored
If an error happens in mtd_device_parse_register or mtd_device_register, memory allocated for struct platram_info is leaked. Make platram_probe() call platram_remove() on all error paths after struct platram_info allocation to correctly free resources. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Baskov Evgeiny <baskov@ispras.ru> Signed-off-by:
-
Thomas Gleixner authored
struct mtd_info has a flag oops_panic_write which is set when the write operation is issued via the panic_write() callback. That allows controller drivers to distinguish the panic write from a regular write. Replace the open coded 'in_interrupt() | oops_in_progress' checks with a check for that flag. in_interrupt() is an unrealiable indicator anyway as it covers all sorts of atomic contexts not only hard and soft interrupt service routines. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: Tudor Ambarus <tudor.ambarus@microchip.com> Cc: Richard Weinberger <richard@nod.at> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: linux-mtd@lists.infradead.org Cc: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Miquel Raynal authored
The raw NAND core now declares the on host ECC engine being the default if none is provided in the DT. Drop this line doing exactly the same from the Marvell driver. Signed-off-by:
-
Miquel Raynal authored
When the nand_chip structure is already available, there is no need to dereference it through the info pointer. Use the chip pointer directly in this case. Signed-off-by:
-
Miquel Raynal authored
While working a bit on this driver I dropped the platform includes and commented a few lines just to verify the correctness of my changes. It appeared the following: drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_waitrdy’: drivers/mtd/nand/raw/au1550nd.c:130:3: error: implicit declaration of function ‘usleep_range’ [-Werror=implicit-function-declaration] usleep_range(10, 100); ^~~~~~~~~~~~ drivers/mtd/nand/raw/au1550nd.c: In function ‘au1550nd_exec_instr’: drivers/mtd/nand/raw/au1550nd.c:188:3: error: implicit declaration of function ‘ndelay’ [-Werror=implicit-function-declaration] ndelay(instr->delay_ns); ^~~~~~ I think the delay.h header should be included in this file and not come from one of its platform includes, so let's add it here. Signed-off-by:
-
Miquel Raynal authored
The NAND ECC core is included in the generic NAND core when it is compiled in. Different software ECC engines drivers will select the NAND ECC core and thus also have a dependency on the NAND core. Using a "depends on" between the two leads to possible cases (not real cases, but created by robots) where one is still unselected because of the "select does not verifies depends on" game: WARNING: unmet direct dependencies detected for MTD_NAND_ECC Depends on [n]: MTD [=m] && MTD_NAND_CORE [=n] Selected by [m]: - MTD_NAND_ECC_SW_HAMMING [=y] && MTD [=m] - MTD_NAND_ECC_SW_BCH [=y] && MTD [=m] Fix this by using a select instead. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Miquel Raynal authored
Moving files around produced the following warnings: Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c Fix one by just dropping the reference because it is not relevant, the other by using a better noun instead of a file name. Signed-off-by: -
Fabio Estevam authored
i.MX is a devicetree-only platform now and the existing platform data support in this driver was only useful for old non-devicetree platforms. Get rid of the platform data support since it is no longer used. Signed-off-by:
-
Yu Kuai authored
of_find_device_by_node() already takes a reference to the device, and ingenic_ecc_release() will drop the reference. So, the get_device() in ingenic_ecc_get() is redundand. Fixes: 15de8c6e("mtd: rawnand: ingenic: Separate top-level and SoC specific code") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Acked-by:
Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Miquel Raynal authored
This code has been written in 2008 and is fine, but in order to keep robots happy, I think it's time to change a little bit this code just to clarify the different possible values of eccsize_mult. Indeed, this variable may only take the value 1 or 2 because step_size, in the case of the software Hamming ECC engine may only be 256 or 512. Depending on the value of eccsize_mult, an extra rp17 variable is set, or not and triggers the following warning: smatch warnings: ecc_sw_hamming_calculate() error: uninitialized symbol 'rp17'. As highlighted by Dan Carpenter, if the only possible values for eccsize_mult are 1 and 2, then the code is fine, but "it's hard to tell just from looking". So instead of shifting step_size, let's use a ternary condition to assign to eccsize_mult the only two possible values and clarify the driver's logic. Now that the situation is clarified for humans, ensure rp17 is initialized to 0 to keep compilers and robots silent as well. Reported-by:kernel test robot <lkp@intel.com> Reported-by:
-
Manuel Dipolt authored
This patch enables NAND MDMA (MBUS DMA) mode for the Allwinner SoCs A23/A33/H3. The DMA transfer method gets sets now to MBUS DMA as default for the sun8i-a23-nand-controller (till now DMA transfer was executed via the shared DMA engine). The main advantage is more bandwidth for the users of the shared DMA engine and also that the MBUS DMA setup requires less configuration effort. For example you don't need to define a dedicated DMA channel in the device-tree any more. Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Manuel Dipolt <manuel.dipolt@robart.cc> Signed-off-by:
-
Sergei Antonov authored
Arguments 'infolen' and 'datalen' to meson_nfc_dma_buffer_release() were mixed up. Fixes: 8fae856c ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Cc: stable@vger.kernel.org Signed-off-by:
Sergei Antonov <saproj@gmail.com> Acked-by:
Liang Yang <liang.yang@amlogic.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Some identifiers have different names between their prototypes and the kernel-doc markup. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Kathiravan T authored
Add the compatible string for IPQ6018 QPIC NAND controller version 1.5.0. It's properties are same as IPQ8074, so reuse the same. Signed-off-by:
Kathiravan T <kathirav@codeaurora.org> Signed-off-by:
-
Kathiravan T authored
Add the binding for the QPIC NAND used on IPQ6018 SoC. Signed-off-by:
-
Praveenkumar I authored
After each codeword NAND_FLASH_STATUS is read for possible operational failures. But there is no DMA sync for CPU operation before reading it and this leads to incorrect or older copy of DMA buffer in reg_read_buf. This patch adds the DMA sync on reg_read_buf for CPU before reading it. Fixes: 5bc36b2b ("mtd: rawnand: qcom: check for operation errors in case of raw read") Cc: stable@vger.kernel.org Signed-off-by:
Praveenkumar I <ipkumar@codeaurora.org> Signed-off-by:
-
Marco Felsch authored
The extra gpmi_nand.o object is not needed anymore since commit 3045f8e3 ("mtd: rawnand: gpmi: move all driver code into single file"). Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Miquel Raynal authored
This comment is no longer true so drop it. Signed-off-by:
-
Miquel Raynal authored
So far OOB have never been used in SPI-NAND, add the missing memcpy to make it work properly. Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Even if this is not supposed to happen, there is no reason to fail the probe if it was explicitly requested to use no ECC engine at all (for instance, during development). This condition is met by just commenting out the error on the OOB free bytes count after the assignation of an ECC engine if none was provided (any other situation would error out much earlier anyway). Signed-off-by:
-
Miquel Raynal authored
Now that all the logic is available in the NAND core, let's use it from the SPI-NAND core. Right now there is no functional change as the default ECC engine for SPI-NANDs is set to 'on-die', but user can now use software correction if they want to by just setting the right properties in the DT. Also note that the OOB layout handling is removed from the SPI-NAND core as each ECC engine is supposed to handle it by it's own; users should not be aware of that. Signed-off-by:
-
Miquel Raynal authored
This property does not describe very well its purpose: it describes the ECC engine type. Deprecate it in favor of nand-ecc-engine which points to either the NAND part itself in case of on-die ECC, or to the parent node in case of an integrated ECC engine in the NAND controller (previously referred as "hardware") or to another node in case of an external controller. Other "modes" (none/software) are achieved with the new nand-use-soft-ecc-engine and nand-no-ecc-engine properties. Signed-off-by:
-
Miquel Raynal authored
Add the logic in the NAND core to find the right ECC engine depending on the NAND chip requirements and the user desires. Right now, the choice may be made between (more will come): * software Hamming * software BCH * on-die (SPI-NAND devices only) Once the ECC engine has been found, the ECC engine must be configured. Signed-off-by:
-
