OMAP4 NAND updates (squash)
found @ bsmitty's repo @ https://github.com/bsmitty83/DirtyV_tuna

 OMAP4: NAND: Fix occasional errors and improve performance

The NAND command functions were not waiting for the attached chip to
indicate ready for some functions that they should have.  The changes
here reflect the use of the ready line by the Micron MT29F NAND Flash
Memory datasheet.

The routine omap_dev_ready() used the WAIT0EDGEDETECTION bit in the
GPMC_IRQSTATUS register.  This bit changes well after the NAND chip
raises the GPMC_WAIT0 input to indicate that it is ready.  The result
is that NAND reads and writes are quite slow.  It takes longer for
WAIT0EDGEDETECTION to reflect the proper status than it does to read
a page of data out of the NAND chip following the read command.  The
driver now uses WAIT0STATUS in the GPMC_STATUS register as per the TRM.

Signed-off-by: Steve Schefter <steve@scheftech.com>

OMAP: NAND BCH: Add eccsize and eccbytes to bcn struct

In the BCH4/8 support for OMAP2 is done only partly in hardware.
The error correction itself is done in software.
To use the lib/bch for error correction some changes have to be in the nand_bch.
The omap uses for bch8 eccsize=2048 and eccbytes=52 but does the
actual check and correction in four sub blocks. So we use in the nand_bch
code the eccsize=512 and eccbytes=13.
The used eccsize/eccbytes have to be saved in the bcn struct.

Signed-off-by: Steve Schefter <steve@scheftech.com>

OMAP4: NAND: use dev ready

Enable the use of the dev ready (GPMC_WAIT0) signal from the NAND
chip.  This increases the performance of NAND access.

This commit also modifies omap_write_buf_pref() to improve
performance and fixes DMA support for NAND.  The latter is not
turned on as it has a negative impact on NAND speed.

Signed-off-by: Steve Schefter <steve@scheftech.com>

Conflicts:
	drivers/mtd/nand/omap2.c

 NAND: timing requirements not met

After the driver issues the commands NAND_CMD_SEQIN and
NAND_CMD_STATUS the chip does not assert the wait line, but it is
not immediately ready.  The driver must wait tADL and tWHR
respectively.

Signed-off-by: Steve Schefter <steve@scheftech.com>

OMAP4: NAND: fix for read error

Because the NAND interface uses the OMAP's general purpose memory
controller, part of the interface is implemented in software.
Specifically, the NAND driver monitors the ready line from the NAND
chip.  This is done using the WAIT0STATUS bit in the GPMC_STATUS
register.  It has been found that this can, on rare occasions for
at the start of a page read, indicate ready when the device is not
really ready to present the data.  Two positive reads produce
reliable results.  See details in omap_dev_ready().

While investigating this change, it was noted that the timing
specs for the NAND chip require a delay of tRR after the chip
indicates ready before it is actually ready to provide the data.
This was implenented in nand_command() and nand_command_lp(),
although no problem was observed without this delay.

Testing indicates that these changes have little or no effect
on the NAND read and write speeds.

Signed-off-by: Steve Schefter <steve@scheftech.com>