- 07 Jan, 2014 4 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> 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 authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 03 Jan, 2014 36 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 authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
-
Jingoo Han authored
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by:
Josh Wu <josh.wu@atmel.com> Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_clk_get() to make cleanup paths simpler. Signed-off-by:
-
Jingoo Han authored
Use devm_kzalloc() to make cleanup paths simpler. Also, checking return value of devm_kzalloc() is added in order to check if the allocation succeded. Signed-off-by:
John Crispin <blogic@openwrt.org> Signed-off-by:
-
Jingoo Han authored
Use devm_*() functions to make cleanup paths simpler. Signed-off-by:
-
Ezequiel Garcia authored
In order to avoid code duplication, let's consolidate the ECC setting for all SoC variants. Such decision is based on page size and ECC strength requirements. Also, provide a default value for the case where such ECC information is not provided (non-ONFI devices). Tested-by:
Arnaud Ebalard <arno@natisbad.org> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Ezequiel Garcia authored
Currently, we have two different cmdfunc's implementations: one for PXA3xx SoC variant and one for Armada 370/XP SoC variant. The former is the legacy one, typically constrained to devices with page sizes smaller or equal to the controller's FIFO buffer. On the other side, the latter _only_ supports the so-called extended command semantics, which allow to handle devices with larger page sizes (4 KiB, 8 KiB, ...). This means we currently don't support devices with smaller pages on the A370/XP SoC. Fix it by first renaming the cmdfuncs variants, and then make the choice based on device page size (and SoC variant), rather than SoC variant alone. While at it, add a check for page size, to make sure we don't allow larger pages sizes on the PXA3xx variant. Tested-by:
-
Ezequiel Garcia authored
Currently the driver assumes all commands will eventually trigger a RnB transition, and thus a "device is ready" IRQ. This assumption means that on every issued command, the dev_ready completion handler is init'ed and the need_wait flag is set. However this is incorrect: some commands (such as NAND_CMD_STATUS) don't make the device 'busy' and thus a RnB transition never occurs. Given, the NAND core never calls waitfunc() after such commands, this is not a problem. Therefore, it's possible to only clear the need_wait flag on every command that is started. This fixes a current bug that can be reproduced on PXA boards by writing blank (all 0xff'ed) to a page: 1. The kernel issues NAND_CMD_STATUS and sets need_wait=1. The flag won't be cleared for this command since no RnB transition is involved. 2. NAND_CMD_PAGEPROG is issued but since the data is blank, the driver decides not to execute the command (and no IRQ activity is involved). 3. The NAND core calls waitfunc() and waits for the dev_ready completion, which will never end since the device _is_ already ready. Tested-by: -
Rashika Kheria authored
This patch marks the function is_erased() as static in denali.c because it is not used outside this file. This patch elimiates the following warning in nand/denali.c: drivers/mtd/nand/denali.c:900:6: warning: no previous prototype for ‘is_erased’ [-Wmissing-prototypes] Signed-off-by:
Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Rashika Kheria authored
This patch marks the functions do_write_buffer() and do_erase_oneblock() as static because because they are not used outside this file. It also removes the unused function word_program() in lpddr/lpddr_cmds.c. Thus, it also removes the following warnings in lpddr/lpddr_cmds.c: drivers/mtd/lpddr/lpddr_cmds.c:391:5: warning: no previous prototype for ‘do_write_buffer’ [-Wmissing-prototypes] drivers/mtd/lpddr/lpddr_cmds.c:472:5: warning: no previous prototype for ‘do_erase_oneblock’ [-Wmissing-prototypes] drivers/mtd/lpddr/lpddr_cmds.c:751:5: warning: no previous prototype for ‘word_program’ [-Wmissing-prototypes] Signed-off-by:
-
Brian Norris authored
This driver doesn't need its own custom chip->write_page callback; the only "custom" requirement is that this driver does not support subpage writes, which we can avoid using the NAND_NO_SUBPAGE_WRITE flag. With NAND_NO_SUBPAGE_WRITE, the default routine (nand_write_page()) should perform the equivalent operations. Signed-off-by:
-
Ivan Khoronzhuk authored
The TI AEMIF driver registers are used to setup timings for each chip select. The same registers range is used to setup NAND settings. The AEMIF and NAND drivers not use the same registers in this range. In case with TI AEMIF driver, the memory address range is requested already by AEMIF, so we cannot request it twice, just ioremap. Acked-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Reviewed-by:
Taras Kondratiuk <taras@ti.com> Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> Signed-off-by:
-
Ivan Khoronzhuk authored
The Keystone arch has compatible nand device, so reuse it. In case with Keystone it depends on TI_AEMIF because AEMIF driver is responsible to set timings. See http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdfReviewed-by:
-
Ivan Khoronzhuk authored
The properties davinci-ecc-mode, davinci-nand-use-bbt, davinci-nand-buswidth are MTD generic. Correct names for them are: nand-ecc-mode, nand-on-flash-bbt, nand-bus-width accordingly. So rename them in dts and documentation. Reviewed-by:
-
Ivan Khoronzhuk authored
Extend bindings for davinci_nand driver to be more clear. This is clarification only, without semantic changes. Reviewed-by:
-
Ivan Khoronzhuk authored
Move bindings under mtd. Do this in order to make davinci-nand driver usable by keystone architecture. Acked-by:
-
Ivan Khoronzhuk authored
There is not needed to use a lot of names for err handling. It complicates code support and reading. Acked-by:
-
Ivan Khoronzhuk authored
The property "ti,davinci-chipselect" is required. So we have to check if it is set. Reviewed-by:
-
Ivan Khoronzhuk authored
In case when memory allocation is failed the driver should return ENOMEM instead of ENODEV. Reviewed-by:
-
Ivan Khoronzhuk authored
When kernel is booted using DT, there is no guarantee that Davinci NAND device has been created already at the time when driver init function is executed. Therefore, platform_driver_probe() can't be used because this may result the Davinci NAND driver will never be probed. The driver probing has to be made with core mechanism. Acked-by:
-
Wei Yongjun authored
Add missing platform_set_drvdata() in au1550nd_probe(), otherwise calling platform_get_drvdata() in remove returns NULL. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
