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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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>
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>
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>
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: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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>
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>
Use devm_*() functions to make cleanup paths simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Roland Stigge <stigge@antcom.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Use devm_clk_get() to make cleanup paths simpler.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Brian 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: Jingoo Han <jg1.han@samsung.com>
Acked-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
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>
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: Brian 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: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian 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: Arnaud Ebalard <arno@natisbad.org>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Brian 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: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Brian 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: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Brian 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: Brian Norris <computersforpeace@gmail.com>
Acked-by: Roland Stigge <stigge@antcom.de>
Tested-by: Roland 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: 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: Brian 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.pdf
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: Brian 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: 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: Brian Norris <computersforpeace@gmail.com>
Extend bindings for davinci_nand driver to be more clear.
This is clarification only, without semantic changes.
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: Brian Norris <computersforpeace@gmail.com>
Move bindings under mtd. Do this in order to make davinci-nand
driver usable by keystone architecture.
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: Brian 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: 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: Brian Norris <computersforpeace@gmail.com>
The property "ti,davinci-chipselect" is required. So we have to check
if it is set.
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: Brian Norris <computersforpeace@gmail.com>
In case when memory allocation is failed the driver should return
ENOMEM instead of ENODEV.
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: Brian 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: 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: Brian Norris <computersforpeace@gmail.com>
Brian Norris
Jingoo Han
Ezequiel Garcia
Rashika Kheria
Ivan Khoronzhuk