- Mar 29, 2018
-
-
Miquel Raynal authored
Prepare the migration of the lpc32xx_slc driver to use nand_scan() by cleaning the error path in the probe function. Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com>
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_parse_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_parse_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_parse_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_parse_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_parse_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Miquel Raynal authored
An error after nand_scan_tail() should trigger a nand_cleanup(). The helper mtd_device_register() returns an error code that should be checked and nand_cleanup() called accordingly. Signed-off-by:
-
Boris Brezillon authored
This mode is not used by any existing setup and should not be used because it overwrites the BBMs. Let's just remove it before someone starts using it. Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Tested-by:
-
Gregory CLEMENT authored
On Armada 7K/8K we need to explicitly enable the register clock. This clock is optional because not all the SoCs using this IP need it but at least for Armada 7K/8K it is actually mandatory. The binding documentation is updated accordingly. Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
- Mar 20, 2018
-
-
Miquel Raynal authored
GPMI driver timings derivation looks very empirical and does not use the known timings that the core wants to use with the NAND chip, by using local defined constants that have no special meaning from the outside world. Simplify the way all of this is computed and use the NAND core's SDR timings. Integrity of the reads/writes has been checked with nandbiterrs, speed improvements with flash_speed on a Freescale i.MX6 DualLite/Solo SABRE Automotive Board. Measures are below, variations of less than 150kiB/s between tests are common and then not significant. Speeds using mode 5 are the same, while speeds using mode 0 are quite improved (+40/50% from non-optimal computation). Forcing timings mode 0: ======================= Before this patch: ------------------ eraseblock write speed is 2298 KiB/s eraseblock read speed is 3636 KiB/s page write speed is 2136 KiB/s page read speed is 3316 KiB/s 2 page write speed is 2199 KiB/s 2 page read speed is 3468 KiB/s After this patch: ----------------- eraseblock write speed is 3232 KiB/s eraseblock read speed is 5663 KiB/s page write speed is 2915 KiB/s page read speed is 4904 KiB/s 2 page write speed is 3084 KiB/s 2 page read speed is 5267 KiB/s Forcing timings mode 5: ======================= Before this patch: ------------------ eraseblock write speed is 4338 KiB/s eraseblock read speed is 14883 KiB/s page write speed is 3786 KiB/s page read speed is 12800 KiB/s 2 page write speed is 4076 KiB/s 2 page read speed is 14065 KiB/s After this patch: ----------------- eraseblock write speed is 4309 KiB/s eraseblock read speed is 14712 KiB/s page write speed is 3764 KiB/s page read speed is 12673 KiB/s 2 page write speed is 4076 KiB/s 2 page read speed is 14065 KiB/s Signed-off-by:
-
Miquel Raynal authored
Until now the GPMI driver had its own timings logic while the core already handles that and request the NAND controller drivers to support the ->setup_data_interface() hook. Implement that hook by reusing the already existing function. No real glue is necessary between core timing delays and GPMI registers because the driver already translates the ONFI timing modes into register values. Make use of the core's tREA, tRLOH and tRHOH values that allow computing more precise timings for mode [0-3] and get significantly better values (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic. Signed-off-by:
Han Xu <han.xu@nxp.com> Signed-off-by:
-
Miquel Raynal authored
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. Now that there is a small nand_parameters structure that hold all needed ONFI parameters, remove the ONFI page from the nand_chip structure by just allocating it during the identification phase and removing it right after. Signed-off-by:
-
Miquel Raynal authored
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. Now that there is a small nand_parameters structure that can held generic parameters, remove the JEDEC page from the nand_chip structure by just allocating it during the identification phase and removing it right after. Signed-off-by:
-
Miquel Raynal authored
The MX30LF2G18AC chip declares in its parameter page supporting SET/GET_FEATURES but when it comes to timings, experience shows that it is not the case. Unflag this feature for this particular chip in the nand_parameters structure to avoid unnecessary errors and downturns. Signed-off-by:
-
Miquel Raynal authored
If SET/GET_FEATURES is available (from the parameter page), use a bitmap to declare what feature is actually supported. Initialize the bitmap in the core to support timing changes (only feature used by the core), also add support for Micron specific features used in Micron initialization code (in the init routine). Signed-off-by:
-
Miquel Raynal authored
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. ONFI-related parameters that will be used outside from the identification function are stored in a separate onfi_parameters structure embedded in nand_parameters, this small structure that already hold generic parameters. For now, the onfi_parameters structure is allocated statically. However, after some deep rework in the NAND framework, it will be possible to do dynamic allocations from the NAND identification phase, and this strcuture will then be dynamically allocated when needed. Signed-off-by:
-
Miquel Raynal authored
The NAND chip parameter page is statically allocated within the nand_chip structure, which reserves a lot of space. Even not ONFI nor JEDEC chips have it embedded. Also, only a few parameters are actually read from the parameter page after the detection. To prepare to the removal of such huge structure, a small NAND parameter structure is allocated statically and contains only very few members that are generic to all chips and actually used elsewhere in the code. Signed-off-by:
-
Miquel Raynal authored
After a nand_reset_data_interface(), both the NAND chip and the NAND controller use timing mode 0. The previously defined data interface for this chip has been saved and is supposed to be restored after that. However, if the saved data interface also refers to timing mode 0, there is no need to re-apply them again. Also, as nand_setup_data_interface() uses ->set/get_features(), it could lead to issues when doing the reset at probe time as the parameter page is not available yet to know if these functions are supported or not. Signed-off-by:
-
Miquel Raynal authored
Choosing ONFI timings when ->set/get_features() calls are supported by the NAND chip is a matter of reading the chip's ONFI parameter page and telling the chip the chosen mode (between all of the supported ones) with ->set_feature(). Add a check on whether the chip "acked" the timing mode or not. This can be a problem for NAND chips that do not follow entirely the ONFI specification. These chips actually support other modes than "mode 0", but either: 1/ do not update the timing mode register once a timing mode has been selected. or 2/ do not support the TIMING_MODE featured and thus do not require users to change the timing mode at all. These issues will be addressed in another patch that will add the feature to overwrite NAND chips features within the parameter page, from the NAND chip driver. Signed-off-by:
-
Miquel Raynal authored
After a ->set_features(TIMINGS), the chip is supposed to be working at a new speed. In order for all the transactions to be perperly handled, the NAND controller should also be configured to this same speed. Calling ->setup_data_interface() is not enough and the chip should be de-asserted/re-asserted through calls to ->select_chip(). Prepare the next change in nand_setup_data_interface() where timings will be checked after being applied. Because assertions of the CS pin will be needed from within this function, move the calls to ->select_chip() inside nand_setup_data_interface() for later consistency. Signed-off-by:
-
Miquel Raynal authored
All the calls to the chip's hooks ->get/set_features() go through the core's wrappers nand_get/set_features() that already do the necessary checks about feature support. Remove these checks from the mxc's functions. Signed-off-by:
-
Miquel Raynal authored
Usually, the source of the error when setting/getting features does not matter (if the controller does not support sending the command or if the chip does not support the operation). When it comes to timings, if the controller fails it is an error while if the chip does not support the operation, it can be silently supposed that it already works with the maximum supported timings. Introduce some logic in nand_setup_data_interface() to handle that difference. Signed-off-by:
-
Miquel Raynal authored
Prepare the fact that some features managed by GET/SET_FEATURES could be overloaded by vendor code. To handle this logic, use new wrappers instead of directly call the ->get/set_features() hooks. Signed-off-by:
-
Miquel Raynal authored
SET/GET FEATURES are flagged ONFI-compliant because of their name. This is not accurate as non-ONFI NAND chips support it and use it. Rename the hooks and helpers to remove the "onfi" prefix. Signed-off-by:
-
Miquel Raynal authored
Prepare future work on the ->onfi_get/set_features() hooks by renaming the core's implementation as 'default' ones. Signed-off-by:
-
- Mar 19, 2018
-
-
Miquel Raynal authored
Files have been moved in the NAND subsystem to reflect the different flavors of NAND devices. Raw/Parallel NAND devices have been moved to a "raw" subdirectory to make the difference with OneNAND and SPI NAND for instance. So adjust the Kconfig entry to clarify things. Signed-off-by:
-
- Mar 17, 2018
-
-
Arnd Bergmann authored
The blackfin architecture is getting removed, so this driver has become obsolete. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Stefan Agner authored
With the move to ->exec_op() the driver should now support ONFI SET/GET_FEATURES commands. Signed-off-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
-
Stefan Agner authored
Now that the driver is using ->exec_op(), remove the old hooks. Signed-off-by:
-
Stefan Agner authored
This reworks the driver to make use of ->exec_op() callback. The command sequencer of the VF610 NFC aligns well with the new ops interface. The operations are translated to a NFC command code while filling the necessary registers. Instead of using the special status and read ID command codes (which require to read status/ID from special registers instead of the regular data area) the driver now now uses the main data buffer for all commands. This simplifies the driver as no special casing is needed. For control data (status byte, id bytes and parameter page) the driver needs to reverse byte order for little endian CPUs since the controller seems to store the bytes in big endian order in the data buffer. The current state seems to pass MTD tests on a Colibri VF61. Signed-off-by:
-
- Mar 15, 2018
-
-
Masahiro Yamada authored
This file can not be built independently any more. We would have to bring in more to resolve mtd_to_nand(mtd)->ecc.size, for example. It is difficult to notice a breakage since nobody compiles this mode. It is not worth fixing or maintaining in my opinion. Remove. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Shreeya Patel authored
Using pr_<loglevel>() is more concise than printk(KERN_<LOGLEVEL>). Replace printks having a log level with the appropriate pr_*() macros. Define pr_fmt() and remove other additional macros from the replaced printks. Signed-off-by:
Shreeya Patel <shreeya.patel23498@gmail.com> Signed-off-by:
-
Boris Brezillon authored
Move onenand code base to the drivers/mtd/nand directory in the hope that someday someone will patch it to use the generic NAND helpers. If it never happens, at least we'll have all NAND related support in a single directory and not spread over the drivers/mtd/ directory. Signed-off-by: -
Boris Brezillon authored
Some files add a comment giving the path of the file inside the Linux tree, which is pretty useless since the reader had to find the file to open it. Getting rid of these comments will also allow us to easily move these files around when needed. Signed-off-by:
-
- Mar 03, 2018
-
-
git://git.infradead.org/linux-mtdBoris Brezillon authored
Remove the pxa3xx_nand driver (replaced by marvell_nand).
-
Miquel Raynal authored
The driver pxa3xx_nand.c has been replaced everywhere by its rework called marvell_nand.c so this entry can now be removed. Signed-off-by:
-
Miquel Raynal authored
Use the new bindings of the reworked Marvell NAND controller driver. Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Miquel Raynal authored
The deprecated pxa3xx_nand.c driver does not exist anymore, it has been replaced by marvell_nand.c which has its own up-to-date documentation. Signed-off-by:
Rob Herring <robh@kernel.org> Tested-by:
-
