- 14 Jan, 2014 3 commits
-
-
Brian Norris authored
Modern MLC (and even SLC?) NAND can experience a large number of bitflips (beyond the recommended correctability capacity) due to drifts in the voltage threshold (Vt). These bitflips can cause ECC errors to occur well within the expected lifetime of the flash. To account for this, some manufacturers provide a mechanism for shifting the Vt threshold after a corrupted read. The generic pattern seems to be that a particular flash has N read retry modes (where N = 0, traditionally), and after an ECC failure, the host should reconfigure the flash to use the next available mode, then retry the read operation. This process repeats until all bitfips can be corrected or until the host has tried all available retry modes. This patch adds the infrastructure support for a vendor-specific/flash-specific callback, used for setting the read-retry mode (i.e., voltage threshold). For now, this patch always returns the flash to mode 0 (the default mode) after a successful read-retry, according to the flowchart found in Micron's datasheets. This may need to change in the future if it is determined that eventually, mode 0 is insufficient for the majority of the flash cells (and so for performance reasons, we should leave the flash in mode 1, 2, etc.). Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Huang Shijie <b32955@freescale.com>
-
Brian Norris authored
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Huang Shijie <b32955@freescale.com>
-
Brian Norris authored
ECC failures can be tracked at the page level, not the do_read_ops level (i.e., a potentially multi-page transaction). This helps prepare for READ RETRY support. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Acked-by: Huang Shijie <b32955@freescale.com>
-
- 13 Jan, 2014 1 commit
-
-
Ezequiel Garcia authored
Now that the driver can support the Armada 370/XP SoC NAND controller, add the devicetree compatible string, enabling its use. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
- 11 Jan, 2014 7 commits
-
-
Huang Shijie authored
This patch kills the NAND_MAX_PAGESIZE/NAND_MAX_OOBSIZE by the following way: 1.) change the @buf field of nand_buf{} from an array to a pointer. also remove the DENALI_BUF_SIZE macro. 2.) Before we call the nand_scan_ident, we allocate a temporary buffer whose size is PAGE_SIZE. 3.) After we finish the nand_scan_ident, we have already getten the page size and oob size. We will allocate the right buffer size again. Signed-off-by: Huang Shijie <shijie8@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Huang Shijie authored
We kill the NAND_MAX_PAGESIZE/NAND_MAX_OOBSIZE by the following way: 1.) Before we call the nand_scan_ident, we allocate a temporary buffer whose size is PAGE_SIZE. 2.) After we finish the nand_scan_ident, we have already getten the page size and oob size. We will allocate the right buffer size again. Signed-off-by: Huang Shijie <shijie8@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Prabhakar Kushwaha authored
mtd.name is assigned to IFC NAND physical address. Assignment type is u32. It is not providing correct physical address of IFC NAND. Update assignment type to u64. Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Cai Zhiyong authored
This patch assigned the type->name to mtd->name when mtd->name is NULL in function "find_full_id_nand". mtd->name is NULL may cause some problem. Signed-off-by: Cai Zhiyong <caizhiyong@huawei.com> Acked-by: Huang Shijie <b32955@freescale.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Sachin Kamat authored
commit 93115b7f ("mtd: onenand/samsung: make regs-onenand.h file local") moved the file to the current location but forgot to remove the pointer to its previous location. Clean it up. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Sachin Kamat authored
Commit c02cecb9 ("ARM: orion: move platform_data definitions") moved the file to the current location but forgot to remove the pointer to its previous location. Clean it up. While at it also change the header file protection macros appropriately. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Sachin Kamat authored
Commit 2203747c ("ARM: omap: move platform_data definitions") moved the files to the current location but forgot to remove the pointer to its previous location. Clean it up. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Pekon Gupta <pekon@ti.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
- 09 Jan, 2014 1 commit
-
-
Josh Triplett authored
The kernel already has this information, and individual drivers shouldn't duplicate that. This also eliminates the use of __DATE__ and __TIME__, which make the build non-deterministic. Signed-off-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
- 07 Jan, 2014 20 commits
-
-
Rafał Miłecki authored
Some devices (like WNDR3700v3) have board_data without MPFR magic, some extra header or extra NVRAM around 0x100. In such case we have to look for another magic which is BD 0B 0D BD (BD probably stands for Board Data). It's located "far far away", so instead of extending buffer add another mtd_read. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Rafał Miłecki authored
Some devices have even nicer-to-recognize CFE thanks to the magic. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Ezequiel Garcia authored
Make this option a hidden one and get a cleaner configuration. This option just selects a common infrastructure for MTD-based devices to expose a block interface. There is no point in allowing a separate enable/disable. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> [Brian: keep symbol as tristate] Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Brian Norris authored
Fixes this sparse warning: CHECK drivers/mtd/onenand/generic.c drivers/mtd/onenand/generic.c:61:62: warning: Using plain integer as NULL pointer Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Brian Norris authored
The omap_{read,write}_buf{8,16}() functions are identical to the default nand_base versions. Just let nand_base assign them in the NAND_OMAP_POLLED case. Signed-off-by: Brian Norris <computersforpeace@gmail.com> Tested-by: Pekon Gupta <pekon@ti.com>
-
Brian Norris authored
We shouldn't try to allocate a resource until we're sure the of_property_read_u64() call didn't fail. This is especially important if we use this code for both CONFIG_OF and !CONFIG_OF builds, since of_property_read_u64() will always return -ENOSYS for !CONFIG_OF. Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use dev_warn() instead of printk() to provide a better message to userspace. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
Use dev_err() instead of printk() to provide a better message to userspace. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Josh Wu <josh.wu@atmel.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Roland Stigge <stigge@antcom.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Roland Stigge <stigge@antcom.de> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
- 03 Jan, 2014 8 commits
-
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com>
-