Move away from platform data configuration and use pure DT approach.
Use generic probe function to deal with OneNAND node and remove now useless
gpmc_probe_onenand_child function. Import sync mode timing calculation
function from mach-omap2/gpmc-onenand.c
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
INT pin (gpio_irq) is not really needed for DMA but only for notification
when a command that needs wait has completed. DMA memcpy can be still used
even without gpio_irq available, so enable it unconditionally.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Second commit in driver history (782b7a367d: "[MTD] [OneNAND] OMAP3:
add delay for GPIO") added quirk for waiting until GPIO line settle.
As DMA was disabled for OMAP2 boards, chances are this problem was
not OMAP3 specific and as it is just one register read, previous
test for SoC type is approximately as expensive as read itself.
Make delay unconditional, which allows removing SoC specific code
alltogether.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
We have 4 functions containing almost identical DMA setup code. Create one
function which can set up the DMA for both read and write and use this in
place for the setup code in the driver.
The new function will use wait_for_completion_io_timeout() and it will
figure out the best data_type to be used for the transfer instead of
hardwiring 32 or 16 bit data.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Pull changes needed for omap OneNAND changes from Roger Quadros:
OMAP-GPMC: driver updates for v4.16
* Error out only if both 'bank-width' and 'gpmc,device-width' DT properties are missing.
Add marvell_nand driver which aims at replacing the existing pxa3xx_nand
driver.
The new driver intends to be easier to understand and follows the brand
new NAND framework rules by implementing hooks for every pattern the
controller might support and referencing them inside a parser object
that will be given to the core at each ->exec_op() call.
Raw accessors are implemented, useful to test/debug memory/filesystem
corruptions. Userspace binaries contained in the mtd-utils package may
now be used and their output trusted.
Most of the DT nodes using the old driver kept non-optimal timings from
the bootloader (even if there was some mechanisms to derive them if the
chip was ONFI compliant). The new default is to implement
->setup_data_interface() and follow the core's decision regarding the
chip.
Thanks to the improved timings, implementation of ONFI mode 5 support
(with EDO managed by adding a delay on data sampling), merging the
commands together and optimizing writes in the command registers, the
new driver may achieve faster throughputs in both directions.
Measurements show an improvement of about +23% read throughput and +24%
write throughput. These measurements have been done with an
Armada-385-DB-AP (4kiB NAND pages forced in 4-bit strength BCH ECC
correction) using the userspace tool 'flash_speed' from the MTD test
suite.
Besides these important topics, the new driver addresses several
unsolved known issues in the old driver which:
- did not work with ECC soft neither with ECC none ;
- relied on naked read/write (which is unchanged) while the NFCv1
embedded in the pxa3xx platforms do not implement it, so several
NAND commands did not actually ever work without any notice (like
reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
- wrote the OOB data correctly, but was not able to read it correctly
past the first OOB data chunk ;
- did not retrieve ECC bytes ;
- used device tree bindings that did not allow more than one NAND chip,
and did not allow to choose the correct chip select if not
incrementing from 0. Plus, the Ready/Busy line used had to be 0.
Old device tree bindings are still supported but deprecated. A more
hierarchical view has to be used to keep the controller and the NAND
chip structures clearly separated both inside the device tree and also
in the driver code.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Tested-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Document the legacy and the new bindings for Marvell NAND controller.
The pxa3xx_nand.c driver does only support legacy bindings, which are
incomplete and inaccurate. A rework of this controller (called
marvell_nand.c) does support both.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
There are already an atmel,rb and an allwinner,rb properties, let's not
make other ones and instead use a generic term: nand-rb to define NAND
chips Ready/Busy lines.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Starting from commit 041e4575f0 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b ("mtd: check for max_bitflips in mtd_read_oob()")
Cc: stable@vger.kernel.org
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reads from NAND devices usually trigger bitflips, this is an expected
behavior. While bitflips are under a given threshold, the MTD core
returns 0. However, when the number of corrected bitflips is above this
same threshold, -EUCLEAN is returned to inform the upper layer that this
block is slightly dying and soon the ECC engine will be overtaken so
actions should be taken to move the data out of it.
This particular condition should not be treated like an error and the
test should continue.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Samsung E-die SLC NAND manufactured using 21nm process (K9F1G08U0E)
does not support partial page programming, so disable subpage writes
for it. Manufacturing process is stored in lowest two bits of 5th ID
byte.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The number of corrected bitflips is not correctly reported by
the test until the bitflip threshold is reached.
read_page() shall return the number of corrected bitflips, but
mtd_read() returns 0 or a negative error, so we can't forward
its return value. In the absence of an error we always have
calculate the number of bitflips ourselves.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
Fixes: 27c5b17cd1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Cc: <stable@vger.kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
If 'mtd_device_parse_register()' fails, we still return 0 which mean
success.
Return the error code instead, as done in all the other error handling
paths.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Convert all error handling code in 's3c_onenand_probe()' to
resource-managed alternatives in order to simplify code.
This fixes a resource leak if 'platform_get_resource()' fails at line 872.
The 'request_irq()' at line 971 was also un-balanced. It is now
resource-managed.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Introduce a new interface to instruct NAND controllers to send specific
NAND operations. The new interface takes the form of a single method
called ->exec_op(). This method is designed to replace ->cmd_ctrl(),
->cmdfunc() and ->read/write_byte/word/buf() hooks.
->exec_op() is passed a set of instructions describing the operation
to execute. Each instruction has a type (ADDR, CMD, DATA, WAITRDY)
and delay. The delay is here to help simple controllers wait enough
time between each instruction, advanced controllers with integrated
timings control can ignore these delays.
Controllers that natively support complex operations (operations
formed of several instructions) can use the NAND op parser
infrastructure. This infrastructure allows controller drivers to
describe the sequence of instructions they support (called
nand_op_pattern) and a hook for each of these supported sequences. The
core then tries to find the best match for a given NAND operation, and
calls the associated hook.
Various other helpers are also added to ease NAND controller drivers
writing.
This new interface should ease support of vendor specific operations
in that NAND manufacturer drivers now have a way to check if the
controller they are connected to supports a specific operation, and
complain or refuse to probe the NAND chip when that's not the case.
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Samsung NAND chip K9F4G08U0D minimum ECC strength requirement is 1 bit
per 512 bytes. As the chip is not ONFI nor JEDEC and because of the lack
of these values, boards using it fail to probe the NAND controller
driver. Fix this by setting up the default values.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The only users of the ecc->{calc,code}_buf buffers are NAND controller
drivers implementing ecc->calculate() and/or ecc->correct(). Since the
->oobsize can be non-negligle, especially on modern NAND devices, we'd
better allocate it only when it is actually required.
Make ecc->{calc,code}_buf allocation dependent on the presence of
ecc->calculate() or ecc->correct().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ECC bytes are contiguous in the ->oob_poi buffer, which means we don't
have to copy them into ->code_buf (here used as a temporary buffer)
before passing them to the nand_check_erased_ecc_chunk() function.
This change will allow us to allocate ecc->{code,calc}_buf only when
ecc->calculate() or ecc->correct() is specified.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
MT7622 uses an MTK's earlier NAND flash controller IP which support
different sector size, max spare size per sector and paraity bits...,
some register's offset and definition also been changed in the NAND
flash controller, this patch is the preparation to support MT7622
NAND flash controller.
MT7622 NFC and ECC engine are similar to MT2701's, except below
differences:
(1)MT7622 NFC's max sector size(ECC data size) is 512 bytes, and
MT2701's is 1024, and MT7622's max sector number is 8.
(2)The parity bit of MT7622 is 13, MT2701 is 14.
(3)MT7622 ECC supports less ECC strength, max to 16 bit ecc strength.
(4)MT7622 supports less spare size per sector, max spare size per
sector is 28 bytes.
(5)Some register's offset are different, include ECC_ENCIRQ_EN,
ECC_ENCIRQ_STA, ECC_DECDONE, ECC_DECIRQ_EN and ECC_DECIRQ_STA.
(6)ENC_MODE of ECC_ENCCNFG register is moved from bit 5-6 to bit 4-5.
Signed-off-by: RogerCC Lin <rogercc.lin@mediatek.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers. Squash this struct into nand_chip.
Move and rename as follows:
chip->buffers->ecccalc -> chip->ecc.calc_buf
chip->buffers->ecccode -> chip->ecc.code_buf
chip->buffers->databuf -> chip->data_buf
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
This driver is the last/only user of NAND_OWN_BUFFERS. Boris suggested
to remove this flag.
Taking a closer look at this driver, it calls dma_alloc_coherent() for
the concatenated area for the DMA bounce buffer + struct nand_buffers,
but the latter does not need to be DMA-coherent; cafe_{write,read}_buf
simply do memcpy() between buffers when usedma==1.
Let's do dma_alloc_coherent() for the DMA bounce buffer in the front,
and leave the nand_buffers allocation to nand_scan_tail(), then rip off
NAND_OWN_BUFFERS.
The magic number, 2112, is still mysterious (hard-coded writesize +
oobsize ?), but this is not our main interest. I am keeping it.
Suggested-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Right now, the chip->data_interface field is populated in
nand_scan_tail(), so after the whole NAND detection has taken place.
This is fine because these timings are not yet used by the core so
early in the probe process, but the situation is about to change with
the introduction of ->exec_op().
Also, by convention, nand_scan_ident() is not supposed to allocate
resources, only nand_scan_tail() can, so this prevent us from
allocating and initializing the data_interface object in
nand_scan_ident().
In order to solve this problem, directly embed a data_interface object
in nand_chip so that we don't have to allocate it, and initialize it to
ONFI SDR mode 0 at the very beginning of nand_scan_ident().
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The core currently send the READ0 and SEQIN+PAGEPROG commands in
nand_do_read/write_ops(). This is inconsistent with
->read/write_oob[_raw]() hooks behavior which are expected to send
these commands.
There's already a flag (NAND_ECC_CUSTOM_PAGE_ACCESS) to inform the core
that a specific controller wants to send the READ/SEQIN+PAGEPROG
commands on its own, but it's an opt-in flag, and existing drivers are
unlikely to be updated to pass it.
Moreover, some controllers cannot dissociate the READ/PAGEPROG commands
from the associated data transfer and ECC engine activation, and
developers have to hack things in their ->cmdfunc() implementation to
handle such complex cases, or have to accept the perf penalty of sending
twice the same command.
To address this problem we are planning on adding a new interface which
is passed all information about a NAND operation (including the amount
of data to transfer) and replacing all calls to ->cmdfunc() to calls to
this new ->exec_op() hook. But, in order to do that, we need to have all
->cmdfunc() calls placed near their associated ->read/write_buf/byte()
calls.
Modify the core and relevant drivers to make NAND_ECC_CUSTOM_PAGE_ACCESS
the default case, and remove this flag.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[miquel.raynal@free-electrons.com: tested, fixed and rebased on nand/next]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This is part of the process of removing direct calls to ->cmdfunc()
outside of the core in order to introduce a better interface to execute
NAND operations.
Here we provide several helpers and make use of them to remove all
direct calls to ->cmdfunc(). This way, we can easily modify those
helpers to make use of the new ->exec_op() interface when available.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
[miquel.raynal@free-electrons.com: rebased and fixed some conflicts]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Error out only if both 'bank-width' and 'gpmc,device-width' are missing.
As 'bank-width' is mostly used for NOR devices and all other devices must
use 'gpmc,device-width' update the error message accordingly.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Roger Quadros <rogerq@ti.com>
The "dma_buf" is not used for a DMA bounce buffer, but for arranging
the transferred data for the syndrome page layout. In fact, it is
used in the PIO mode as well, so "dma_buf" is a misleading name.
Rename it to "tmp_buf".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
'extern' is not necessary for function declarations.
scripts/checkpatch.pl with --strict option reports the following:
CHECK: extern prototypes should be avoided in .h files
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
