- 12 Jan, 2018 6 commits
-
-
Miquel Raynal authored
Add marvell_nand driver which aims at replacing the existing pxa3xx_nand driver. The new driver intends to be easier to understand and follows the brand new NAND framework rules by implementing hooks for every pattern the controller might support and referencing them inside a parser object that will be given to the core at each ->exec_op() call. Raw accessors are implemented, useful to test/debug memory/filesystem corruptions. Userspace binaries contained in the mtd-utils package may now be used and their output trusted. Most of the DT nodes using the old driver kept non-optimal timings from the bootloader (even if there was some mechanisms to derive them if the chip was ONFI compliant). The new default is to implement ->setup_data_interface() and follow the core's decision regarding the chip. Thanks to the improved timings, implementation of ONFI mode 5 support (with EDO managed by adding a delay on data sampling), merging the commands together and optimizing writes in the command registers, the new driver may achieve faster throughputs in both directions. Measurements show an improvement of about +23% read throughput and +24% write throughput. These measurements have been done with an Armada-385-DB-AP (4kiB NAND pages forced in 4-bit strength BCH ECC correction) using the userspace tool 'flash_speed' from the MTD test suite. Besides these important topics, the new driver addresses several unsolved known issues in the old driver which: - did not work with ECC soft neither with ECC none ; - relied on naked read/write (which is unchanged) while the NFCv1 embedded in the pxa3xx platforms do not implement it, so several NAND commands did not actually ever work without any notice (like reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ; - wrote the OOB data correctly, but was not able to read it correctly past the first OOB data chunk ; - did not retrieve ECC bytes ; - used device tree bindings that did not allow more than one NAND chip, and did not allow to choose the correct chip select if not incrementing from 0. Plus, the Ready/Busy line used had to be 0. Old device tree bindings are still supported but deprecated. A more hierarchical view has to be used to keep the controller and the NAND chip structures clearly separated both inside the device tree and also in the driver code. Signed-off-by:
Miquel Raynal <miquel.raynal@free-electrons.com> Tested-by:
Sean Nyekjaer <sean.nyekjaer@prevas.dk> Tested-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
Miquel Raynal authored
Document the legacy and the new bindings for Marvell NAND controller. The pxa3xx_nand.c driver does only support legacy bindings, which are incomplete and inaccurate. A rework of this controller (called marvell_nand.c) does support both. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Miquel Raynal authored
There are already an atmel,rb and an allwinner,rb properties, let's not make other ones and instead use a generic term: nand-rb to define NAND chips Ready/Busy lines. Signed-off-by:
-
Miquel Raynal authored
Starting from commit 041e4575 ("mtd: nand: handle ECC errors in OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a negative error, and the MTD layer expected it. However, the trend for the NAND layer is now to return an error or a positive number of bitflips. Deciding which status to return to the user belongs to the MTD layer. Commit e47f6858 ("mtd: check for max_bitflips in mtd_read_oob()") brought this logic to the mtd_read_oob() function while the return value coming from nand_do_read_oob() (called by the ->_read_oob() hook) was left unchanged. Fixes: e47f6858 ("mtd: check for max_bitflips in mtd_read_oob()") Cc: stable@vger.kernel.org Signed-off-by:
-
Miquel Raynal authored
Reads from NAND devices usually trigger bitflips, this is an expected behavior. While bitflips are under a given threshold, the MTD core returns 0. However, when the number of corrected bitflips is above this same threshold, -EUCLEAN is returned to inform the upper layer that this block is slightly dying and soon the ECC engine will be overtaken so actions should be taken to move the data out of it. This particular condition should not be treated like an error and the test should continue. Signed-off-by:
-
Nicolas Ferre authored
Update Wenyou Yang email address. Take advantage of this update to move this entry to the MICROCHIP / ATMEL location and add the DT binding documentation link. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by:
Wenyou Yang <wenyou.yang@microchip.com> Signed-off-by:
-
- 10 Jan, 2018 1 commit
-
-
Ladislav Michl authored
Samsung E-die SLC NAND manufactured using 21nm process (K9F1G08U0E) does not support partial page programming, so disable subpage writes for it. Manufacturing process is stored in lowest two bits of 5th ID byte. Signed-off-by:
Ladislav Michl <ladis@linux-mips.org> Signed-off-by:
-
- 09 Jan, 2018 2 commits
-
-
Sascha Hauer authored
The number of corrected bitflips is not correctly reported by the test until the bitflip threshold is reached. read_page() shall return the number of corrected bitflips, but mtd_read() returns 0 or a negative error, so we can't forward its return value. In the absence of an error we always have calculate the number of bitflips ourselves. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Kamal Dasu authored
Brcm nand controller prefetch feature needs to be disabled by default. Enabling affects performance on random reads as well as dma reads. Signed-off-by:
Kamal Dasu <kdasu.kdev@gmail.com> Fixes: 27c5b17c ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Cc: <stable@vger.kernel.org> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
- 06 Jan, 2018 3 commits
-
-
Fabio Estevam authored
devm_kasprintf() may fail, so we should better add a NULL check and propagate an error on failure. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Fabio Estevam authored
devm_kasprintf() may fail, so we should better add a NULL check and propagate an error on failure. Signed-off-by:
-
Miquel Raynal authored
Give an unfinished comment a meaning. Signed-off-by:
-
- 18 Dec, 2017 4 commits
-
-
Christophe JAILLET authored
This include is not needed, so remove it. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
Propagate the error code returned by 'onenand_scan()' instead of a hard-coded -EFAULT. Signed-off-by:
-
Christophe JAILLET authored
If 'mtd_device_parse_register()' fails, we still return 0 which mean success. Return the error code instead, as done in all the other error handling paths. Signed-off-by:
-
Christophe JAILLET authored
Convert all error handling code in 's3c_onenand_probe()' to resource-managed alternatives in order to simplify code. This fixes a resource leak if 'platform_get_resource()' fails at line 872. The 'request_irq()' at line 971 was also un-balanced. It is now resource-managed. Signed-off-by:
-
- 16 Dec, 2017 1 commit
-
-
Miquel Raynal authored
Introduce a new interface to instruct NAND controllers to send specific NAND operations. The new interface takes the form of a single method called ->exec_op(). This method is designed to replace ->cmd_ctrl(), ->cmdfunc() and ->read/write_byte/word/buf() hooks. ->exec_op() is passed a set of instructions describing the operation to execute. Each instruction has a type (ADDR, CMD, DATA, WAITRDY) and delay. The delay is here to help simple controllers wait enough time between each instruction, advanced controllers with integrated timings control can ignore these delays. Controllers that natively support complex operations (operations formed of several instructions) can use the NAND op parser infrastructure. This infrastructure allows controller drivers to describe the sequence of instructions they support (called nand_op_pattern) and a hook for each of these supported sequences. The core then tries to find the best match for a given NAND operation, and calls the associated hook. Various other helpers are also added to ease NAND controller drivers writing. This new interface should ease support of vendor specific operations in that NAND manufacturer drivers now have a way to check if the controller they are connected to supports a specific operation, and complain or refuse to probe the NAND chip when that's not the case. Suggested-by:
-
- 14 Dec, 2017 14 commits
-
-
Miquel Raynal authored
Samsung NAND chip K9F4G08U0D minimum ECC strength requirement is 1 bit per 512 bytes. As the chip is not ONFI nor JEDEC and because of the lack of these values, boards using it fail to probe the NAND controller driver. Fix this by setting up the default values. Signed-off-by:
-
Boris Brezillon authored
The only users of the ecc->{calc,code}_buf buffers are NAND controller drivers implementing ecc->calculate() and/or ecc->correct(). Since the ->oobsize can be non-negligle, especially on modern NAND devices, we'd better allocate it only when it is actually required. Make ecc->{calc,code}_buf allocation dependent on the presence of ecc->calculate() or ecc->correct(). Signed-off-by:Masahiro Yamada <yamada.masahiro@socionext.com>
-
Boris Brezillon authored
ECC bytes are contiguous in the ->oob_poi buffer, which means we don't have to copy them into ->code_buf (here used as a temporary buffer) before passing them to the nand_check_erased_ecc_chunk() function. This change will allow us to allocate ecc->{code,calc}_buf only when ecc->calculate() or ecc->correct() is specified. Signed-off-by: -
RogerCC Lin authored
Add tables to support MT7622 NAND flash controller. Signed-off-by:
RogerCC Lin <rogercc.lin@mediatek.com> Signed-off-by:
-
RogerCC Lin authored
MT7622 uses an MTK's earlier NAND flash controller IP which support different sector size, max spare size per sector and paraity bits..., some register's offset and definition also been changed in the NAND flash controller, this patch is the preparation to support MT7622 NAND flash controller. MT7622 NFC and ECC engine are similar to MT2701's, except below differences: (1)MT7622 NFC's max sector size(ECC data size) is 512 bytes, and MT2701's is 1024, and MT7622's max sector number is 8. (2)The parity bit of MT7622 is 13, MT2701 is 14. (3)MT7622 ECC supports less ECC strength, max to 16 bit ecc strength. (4)MT7622 supports less spare size per sector, max spare size per sector is 28 bytes. (5)Some register's offset are different, include ECC_ENCIRQ_EN, ECC_ENCIRQ_STA, ECC_DECDONE, ECC_DECIRQ_EN and ECC_DECIRQ_STA. (6)ENC_MODE of ECC_ENCCNFG register is moved from bit 5-6 to bit 4-5. Signed-off-by:
-
RogerCC Lin authored
Add MT7622 NAND Flash Controller dt bindings documentation. Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by:
-
Ladislav Michl authored
Samsung website no longer host information about OneNAND, delete it. Signed-off-by:
-
Masahiro Yamada authored
Use macros from <linux/kernel.h> to make the code readable. The compiler warning will be kept suppressed. Signed-off-by:
-
Masahiro Yamada authored
struct nand_buffers is malloc'ed in nand_scan_tail() just for containing three pointers. Squash this struct into nand_chip. Move and rename as follows: chip->buffers->ecccalc -> chip->ecc.calc_buf chip->buffers->ecccode -> chip->ecc.code_buf chip->buffers->databuf -> chip->data_buf Signed-off-by:
-
Masahiro Yamada authored
The last/only user of NAND_OWN_BUFFERS (cafe_nand.c) has been reworked. This flag is no longer needed. Suggested-by:
-
Masahiro Yamada authored
This driver is the last/only user of NAND_OWN_BUFFERS. Boris suggested to remove this flag. Taking a closer look at this driver, it calls dma_alloc_coherent() for the concatenated area for the DMA bounce buffer + struct nand_buffers, but the latter does not need to be DMA-coherent; cafe_{write,read}_buf simply do memcpy() between buffers when usedma==1. Let's do dma_alloc_coherent() for the DMA bounce buffer in the front, and leave the nand_buffers allocation to nand_scan_tail(), then rip off NAND_OWN_BUFFERS. The magic number, 2112, is still mysterious (hard-coded writesize + oobsize ?), but this is not our main interest. I am keeping it. Suggested-by: -
Miquel Raynal authored
Right now, the chip->data_interface field is populated in nand_scan_tail(), so after the whole NAND detection has taken place. This is fine because these timings are not yet used by the core so early in the probe process, but the situation is about to change with the introduction of ->exec_op(). Also, by convention, nand_scan_ident() is not supposed to allocate resources, only nand_scan_tail() can, so this prevent us from allocating and initializing the data_interface object in nand_scan_ident(). In order to solve this problem, directly embed a data_interface object in nand_chip so that we don't have to allocate it, and initialize it to ONFI SDR mode 0 at the very beginning of nand_scan_ident(). Signed-off-by:
-
Boris Brezillon authored
The core currently send the READ0 and SEQIN+PAGEPROG commands in nand_do_read/write_ops(). This is inconsistent with ->read/write_oob[_raw]() hooks behavior which are expected to send these commands. There's already a flag (NAND_ECC_CUSTOM_PAGE_ACCESS) to inform the core that a specific controller wants to send the READ/SEQIN+PAGEPROG commands on its own, but it's an opt-in flag, and existing drivers are unlikely to be updated to pass it. Moreover, some controllers cannot dissociate the READ/PAGEPROG commands from the associated data transfer and ECC engine activation, and developers have to hack things in their ->cmdfunc() implementation to handle such complex cases, or have to accept the perf penalty of sending twice the same command. To address this problem we are planning on adding a new interface which is passed all information about a NAND operation (including the amount of data to transfer) and replacing all calls to ->cmdfunc() to calls to this new ->exec_op() hook. But, in order to do that, we need to have all ->cmdfunc() calls placed near their associated ->read/write_buf/byte() calls. Modify the core and relevant drivers to make NAND_ECC_CUSTOM_PAGE_ACCESS the default case, and remove this flag. Signed-off-by:
-
Boris Brezillon authored
This is part of the process of removing direct calls to ->cmdfunc() outside of the core in order to introduce a better interface to execute NAND operations. Here we provide several helpers and make use of them to remove all direct calls to ->cmdfunc(). This way, we can easily modify those helpers to make use of the new ->exec_op() interface when available. Signed-off-by:
-
- 01 Dec, 2017 1 commit
-
-
Miquel Raynal authored
Avoid using specific defined values for checking returned status of the ->erase() hook. Instead, use usual negative error values on failure, zero otherwise. Signed-off-by:
-
- 30 Nov, 2017 8 commits
-
-
Masahiro Yamada authored
The "dma_buf" is not used for a DMA bounce buffer, but for arranging the transferred data for the syndrome page layout. In fact, it is used in the PIO mode as well, so "dma_buf" is a misleading name. Rename it to "tmp_buf". Signed-off-by:
-
Masahiro Yamada authored
'extern' is not necessary for function declarations. scripts/checkpatch.pl with --strict option reports the following: CHECK: extern prototypes should be avoided in .h files Signed-off-by:
-
Jagdish Gediya authored
Bufnum mask is used to calculate page position in the internal SRAM. As IFC version 2.0.0 has 16KB of internal SRAM as compared to older versions which had 8KB. Hence bufnum mask needs to be updated. Signed-off-by:
Jagdish Gediya <jagdish.gediya@nxp.com> Signed-off-by:
Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> Signed-off-by:
-
Jesse Chan authored
This change resolves a new compile-time warning when built as a loadable module: WARNING: modpost: missing MODULE_LICENSE() in drivers/mtd/nand/denali_pci.o see include/linux/module.h for more information This adds the license as "GPL v2", which matches the header of the file. MODULE_DESCRIPTION and MODULE_AUTHOR are also added. Signed-off-by:
Jesse Chan <jc@linux.com> Acked-by:
-
Sascha Hauer authored
The GPMI nand Kconfig help texts mentions that the GPMI nand driver might conflict with SD cards. The only conflict there might really be is that both controllers use the same pins, but this is resolved by the pincontroller setup in the device tree. In any way the GPMI driver can safely be enabled, the text is just wrong. Remove it. Signed-off-by:
Han Xu <han.xu@nxp.com> Signed-off-by:
-
Boris Brezillon authored
Setting read-retry parameters has no impact on the R/B pin, so waiting for the chip to be ready is useless. Signed-off-by: -
Miquel Raynal authored
Some drivers (like nand_hynix.c) call ->cmdfunc() with NAND_CMD_NONE and a column address and expect the controller to only send address cycles. Right now, the default ->cmdfunc() implementations provided by the core do not filter out the command cycle in this case and forwards the request to the controller driver through the ->cmd_ctrl() method. The thing is, NAND controller drivers can get this wrong and send a command cycle with a NAND_CMD_NONE opcode and since NAND_CMD_NONE is -1, and the command field is usually casted to an u8, we end up sending the 0xFF command which is actually a RESET operation. Add conditions in nand_command[_lp]() functions to sending the initial command cycle when command == NAND_CMD_NONE. Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the swap macro and remove unnecessary variables swap. This makes the code easier to read and maintain. This code was detected with the help of Coccinelle. Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by:
-
