The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The site-specific OOM messages are unnecessary, because they
duplicate the MM subsystem generic OOM message.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NJosh Wu <josh.wu@atmel.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_clk_get() to make cleanup paths simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NJingoo Han <jg1.han@samsung.com>
Acked-by: NJohn Crispin <blogic@openwrt.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NRashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NBrian Norris <computersforpeace@gmail.com>
Acked-by: NRoland Stigge <stigge@antcom.de>
Tested-by: NRoland Stigge <stigge@antcom.de>

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: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Extend bindings for davinci_nand driver to be more clear.
This is clarification only, without semantic changes.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Move bindings under mtd. Do this in order to make davinci-nand
driver usable by keystone architecture.
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

There is not needed to use a lot of names for err handling.
It complicates code support and reading.
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The property "ti,davinci-chipselect" is required. So we have to check
if it is set.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In case when memory allocation is failed the driver should return
ENOMEM instead of ENODEV.
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

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: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: NTaras Kondratiuk <taras@ti.com>
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Add missing platform_set_drvdata() in au1550nd_probe(), otherwise
calling platform_get_drvdata() in remove returns NULL.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>