Let's use a helper to clearly check if an operation is supported or not.

Return -ENOTSUPP when ->exec_op() is not implemented as we cannot know.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-8-miquel.raynal@bootlin.com

The logic in nand_do_read_ops() is to use a bufpoi variable, either
set to the original buffer, or set to a bounce buffer which in the end
happens to be chip->data_buf depending on the value of the
use_bounce_buf boolean. This is not a reason to call chip->data_buf
directly when we know that we are using the bounce buffer. Let's use
bufpoi instead to be consistent.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-7-miquel.raynal@bootlin.com

Both in nand_do_read_ops() and nand_do_write_ops() there is a boolean
called use_bufpoi which is set to true in case of unaligned request or
when there is a need for a DMA-able buffer. It basically means "use a
bounce buffer".

Depending on the value of use_bufpoi, the bufpoi variable is always
used and will either point to the original buffer or to the nand_chip
structure "internal data buffer" (this buffer is allocated with
kmalloc() on purpose so that it will be DMA-compliant).

In all cases bufpoi is used so the boolean name is misleading. Rename
use_bufpoi to be use_bouce_buf to be more accurate.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-6-miquel.raynal@bootlin.com

Clarify these comments which are not very accurate (even wrong in the
read case).
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-5-miquel.raynal@bootlin.com

NAND controller drivers can set the NAND_USE_BOUNCE_BUFFER flag to a
chip 'option' field. With this flag, the core is responsible of
providing DMA-able buffers.

The current behavior is to not force the use of a bounce buffer when
the core thinks this is not needed. So in the end the name is a bit
misleading, because in theory we will always have a DMA buffer but in
practice it will not always be a bounce buffer.

Rename this flag NAND_USES_DMA to be more accurate.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-4-miquel.raynal@bootlin.com

These flags are in a strange order, reorder the list, add spaces when
it is relevant, pack definitions that are related.

There is no functional change.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-3-miquel.raynal@bootlin.com

Use the BIT() macro instead of defining a 8-digit value.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200507105241.14299-2-miquel.raynal@bootlin.com

The MTD layer provides an SLC mode (purely software emulation of SLC
behavior) addressing the paired-pages corruption issue, which was the
main reason for refusing attaching MLC NANDs to UBI.

Relax this rule and allow partitions that have the
MTD_EMULATE_SLC_ON_MLC flag set to be attached.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Acked-by: NRichard Weinberger <richard@nod.at>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-9-miquel.raynal@bootlin.com

Add a new option to set the MTD_SLC_ON_MLC_EMULATION flag.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-8-miquel.raynal@bootlin.com

Parse the slc-mode property and set the MTD_MLC_IN_SLC_MODE flag
when present.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-7-miquel.raynal@bootlin.com

Add a boolean property to force a specific partition attached to an MLC
NAND to be accessed in an emulated SLC mode this making this partition
immune to paired-pages corruptions.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-6-miquel.raynal@bootlin.com

MLC NANDs can be made a bit more reliable if we only program the lower
page of each pair. At least, this solves the paired-pages corruption
issue.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-5-miquel.raynal@bootlin.com

TC58TEG5DCLTA00 uses a stride of 3 between its lower and upper page.
Set the appropriate pairing scheme at init time.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-4-miquel.raynal@bootlin.com

Define a new page pairing scheme for MLC NANDs with a distance of 3
pages between the lower and upper page.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-3-miquel.raynal@bootlin.com

TC58TEG5DCLTA00 is an MLC NAND which requires scrambling and supports
SDR timings mode 5.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200503155341.16712-2-miquel.raynal@bootlin.com

Now that exec_op() is implemented we no longer need to implement the
legacy hooks.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200501090650.1138200-5-boris.brezillon@collabora.com

So we can later get rid of the legacy hooks.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200501090650.1138200-4-boris.brezillon@collabora.com

Now that we have our own controller struct we can keep the MMIO pointer
in there and use instead of using the chip->legacy.IO_ADDR_{R,W} fields.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200501090650.1138200-3-boris.brezillon@collabora.com

The CS553x companion chip embeds 4 NAND controllers. Declare them as
NAND controllers instead of NAND chips. That's done in preparation
of the transition to exec_op().
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200501090650.1138200-2-boris.brezillon@collabora.com

Before reworking a little bit the JEDEC detection code, let's
clean the coding style of an if statement to improve readability.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-10-miquel.raynal@bootlin.com

Use a macro to define the number of parameter page instead of
hardcoding it everywhere.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-9-miquel.raynal@bootlin.com

During detection the logic on the NAND bus is:

    /* Regular ONFI detection */
    1/ read the three NAND parameter pages

    /* Extended parameter page detection */
    2/ send "read the NAND parameter page" commands without reading
       actual data
    3/ move the column pointer to the extended page and read it

If fact, as long as there is nothing happening on the NAND bus between
1/ and 3/, the operation 2/ is redundant so remove it.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-8-miquel.raynal@bootlin.com

There is no need for copying the parameter page, playing with
pointers does the trick.

There is not functional change.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-7-miquel.raynal@bootlin.com

Use a macro to define the number of parameter page instead of
hardcoding it everywhere.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-6-miquel.raynal@bootlin.com

Before reworking a little bit the ONFI detection code, let's
clean the coding style of the if statements to improve readability.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-5-miquel.raynal@bootlin.com

During ONFI detection, the CRC derived from the parameter page and the
CRC supposed to be at the end of the parameter page are compared. If
they do not match, the second then the third copies of the page are
tried.

The current implementation compares the newly derived CRC with the CRC
contained in the first page only. So if this particular CRC area has
been corrupted, then the detection will fail for a wrong reason.

Fix this issue by checking the derived CRC against the right one.

Fixes: 39138c1f ("mtd: rawnand: use bit-wise majority to recover the ONFI param page")
Cc: stable@vger.kernel.org
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-4-miquel.raynal@bootlin.com

tR and tCCS are currently wrongly expressed in femtoseconds, while we
expect these values to be expressed in picoseconds. Set right
hardcoded values.

Fixes: 6a943386 mtd: rawnand: add default values for dynamic timings
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-3-miquel.raynal@bootlin.com

Convert the timings union into a structure containing the mode and the
actual values. The values are still a union in prevision of the
addition of the NVDDR modes.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200428094302.14624-2-miquel.raynal@bootlin.com

There is no correction involved at this point, it is just a matter of
reading registers and checking whether bitflips have occurred or
not. Rename the function to clarify it.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-7-miquel.raynal@bootlin.com

Cosmetic change to clarify the purpose of the function.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-6-miquel.raynal@bootlin.com

Ensure all chips are deregistered and cleaned in case of error during
the probe.

Fixes: 02f26ecf ("mtd: nand: add reworked Marvell NAND controller driver")
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-5-miquel.raynal@bootlin.com

Do not call nand_release() while the MTD device has not been
registered, use nand_cleanup() instead.

Fixes: 02f26ecf ("mtd: nand: add reworked Marvell NAND controller driver")
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-4-miquel.raynal@bootlin.com

Switch from the old platform_get_resource()/devm_ioremap_resource()
couple to the newer devm_platform_ioremap_resource() helper.
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-3-miquel.raynal@bootlin.com

In a previous fix, I changed the condition on which the timeout of an
IRQ is reached from:

    if (!ret)

into:

    if (ret && !pending)

While having a non-zero return code is usual in the Linux kernel, here
ret comes from a wait_for_completion_timeout() which returns 0 when
the waiting period is too long.

Hence, the revised condition should be:

    if (!ret && !pending)

The faulty patch did not produce any error because of the !pending
condition so this change is finally purely cosmetic and does not
change the actual driver behavior.

Fixes: cafb56dd ("mtd: rawnand: marvell: prevent timeouts on a loaded machine")
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Link: https://lore.kernel.org/linux-mtd/20200424164501.26719-2-miquel.raynal@bootlin.com

When the ECC strength is too weak compared to the NAND chip
requirements, display the values so that it is clear for people how
much they are far from the requirements (and might get in troubles in
the future).
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200421163906.7515-1-miquel.raynal@bootlin.com

To match the types passed by au1550nd_exec_instr() function.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200419193037.1544035-5-boris.brezillon@collabora.com

Now that exec_op() is implemented we can get rid of all other hooks.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200419193037.1544035-4-boris.brezillon@collabora.com

So we can later get rid of the legacy interface implementation.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200419193037.1544035-3-boris.brezillon@collabora.com

We are about to re-use those for the exec_op() implementation which
will not rely on au1550_hwcontrol(). Let's patch those helpers to
simply use the iomem address stored in the context.
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200419193037.1544035-2-boris.brezillon@collabora.com

The Denali IP have several registers to specify how many clock cycles
should be waited between falling/rising signals. You can improve the
NAND access performance by programming these registers with optimized
values.

Because struct nand_sdr_timings represents the device requirement
in pico seconds, denali_setup_data_interface() computes the register
values by dividing the device timings with the clock period.

Marek Vasut reported this driver in the latest kernel does not work
on his SOCFPGA board. (The on-board NAND chip is mode 5)

The suspicious parameter is acc_clks, so this commit relaxes it.

The Denali NAND Flash Memory Controller User's Guide describes this
register as follows:

  acc_clks
    signifies the number of bus interface clk_x clock cycles,
    controller should wait from read enable going low to sending
    out a strobe of clk_x for capturing of incoming data.

Currently, acc_clks is calculated only based on tREA, the delay on the
chip side. This does not include additional delays that come from the
data path on the PCB and in the SoC, load capacity of the pins, etc.

This relatively becomes a big factor on faster timing modes like mode 5.

Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
the timing mode 5.

We would not go back to the hard-coded acc_clks, but we need to include
this factor into the delay somehow. Let's say the amount of the additional
delay is 10000 pico sec.

In the new calculation, acc_clks is determined by timings->tREA_max +
data_setup_on_host.

Also, prolong the RE# low period to make sure the data hold is met.

Finally, re-center the data latch timing for extra safety.

[1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
[2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282Reported-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200317071821.9916-1-yamada.masahiro@socionext.com