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#L282
Reported-by: Marek Vasut <marex@denx.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20200317071821.9916-1-yamada.masahiro@socionext.com
5756f2e8da