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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NBoris Brezillon <boris.brezillon@bootlin.com>
Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: NMiquel Raynal <miquel.raynal@bootlin.com>

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: NGregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Tested-by: NHan Xu <han.xu@nxp.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Tested-by: NHan Xu <han.xu@nxp.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Prepare future work on the ->onfi_get/set_features() hooks by renaming
the core's implementation as 'default' ones.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The blackfin architecture is getting removed, so this driver has
become obsolete.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

With the move to ->exec_op() the driver should now support ONFI
SET/GET_FEATURES commands.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Now that the driver is using ->exec_op(), remove the old
hooks.
Signed-off-by: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NStefan Agner <stefan@agner.ch>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NShreeya Patel <shreeya.patel23498@gmail.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NBoris Brezillon <boris.brezillon@bootlin.com>

Remove the pxa3xx_nand driver (replaced by marvell_nand).

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Use the new bindings of the reworked Marvell NAND controller driver.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

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: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

The "enable arbiter" bit is available only for pxa3xx based platforms
but it was experimentally shown that even if this bit is reserved,
some Marvell platforms (64-bit) actually need it to be set. The driver
always set this bit regardless of this property, which is harmless.
Then this property is not needed.

The "num_cs" field is always 1 and for a good reason, the old driver
(pxa3xx_nand.c) could only handle one. The new driver that replaces it
(marvell_nand.c) can handle more, but better use device tree for such
description. As there is only one available chip select, there is no
need for an array of partitions neither an array of partition numbers.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

All board files and defconfig files have been moved to use the new
marvell_nand driver instead of pxa3xx_nand, so we can safely remove this
file now. People should use the new driver which is supposed to behave
exactly like the old one.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Compile marvell_nand.c instead of pxa3xx_nand.c with all PXA based SoCs.
Convert all board files and defconfigs so that the new driver is used
everywhere instead of the old one.

Board files using CONFIG_MTD_NAND_PXA3xx now use CONFIG_MTD_NAND_MARVELL
instead.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Free Electrons is now Bootlin.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Free Electrons is now Bootlin.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Remove the deprecated ->cmd_ctrl() implementation to use ->exec_op() in
the fsmc_nand driver.

Implement the ->select_chip() hook to avoid having to support the hack
from the core that send a NAND_CMD_NONE with NAND_NCE to signal a
deassertion of nCE.

Also get rid of the last references to ->IO_ADDR_[R|W] that are not used
anymore.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Remove the use of IO_ADDR_[R|W] in the fsmc_nand driver. Instead, use a
pointer to the control registers to avoid doing several arithmetic
operations (including a multiplication) each time a control register is
read or written.

All references to IO_ADDR_[R|W] are not entirely removed from the driver
as, at this time, these values are needed by the NAND core in the
default ->read/write_byte/word() hooks. These references will be
entirely removed when switching to ->exec_op(), that does not make use
of these hooks anymore.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>

Add an intermediate layer to abstract NAND device interface so that
some logic can be shared between SPI NANDs, parallel/raw NANDs,
OneNANDs, ...
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>