For v3.12 and prior, 1-bit Hamming code ECC via software was the
default choice. Commit c66d0391 in v3.13 changed the behaviour
to use 1-bit Hamming code via Hardware using a different ECC layout
i.e. (ROM code layout) than what is used by software ECC.

This ECC layout change causes NAND filesystems created in v3.12
and prior to be unusable in v3.13 and later. So revert back to
using software ECC by default if an ECC scheme is not explicitely
specified.

This defect can be observed on the following boards during legacy boot

-omap3beagle
-omap3touchbook
-overo
-am3517crane
-devkit8000
-ldp
-3430sdp
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

 Fixes:  2c9f2365
 mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch4 in omap_calculate_ecc_bch

 Fixes: 7bcd1dca
 mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch8 in omap_calculate_ecc_bch

Cc: <stable@vger.kernel.org> # 3.13.x+
Signed-off-by: NTed Juan <ted.juan@gmail.com>
Acked-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch add support for BCH16 ecc-scheme in OMAP NAND driver, by extending
following functions:
 - omap_enable_hwecc (nand_chip->ecc.hwctl): configure GPMC controller
 - omap_calculate_ecc_bch (nand_chip->ecc.calculate): fetch ECC signature from GPMC controller
 - omap_elm_correct_data (nand_chip->ecc.correct): detect and correct ECC errors using ELM

(a) BCH16 ecc-scheme can detect and correct 16 bit-flips per 512Bytes of data.
(b) BCH16 ecc-scheme generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy the relation: "OOBsize per page >= 26 * (page-size / 512)"
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

fixes: commit 62116e51
       mtd: nand: omap2: Support for hardware BCH error correction.

In omap_elm_correct_data(), if bitflip_count in an erased-page is within the
correctable limit (< ecc.strength), then it is not indicated back to the caller
ecc->read_page().

This mis-guides upper layers like MTD and UBIFS layer to assume erased-page as
perfectly clean and use it for writing even if actual bitflip_count was
dangerously high (bitflip_count > mtd->bitflip_threshold).

This patch fixes this above issue, by returning 'stats' to caller
ecc->read_page() under all scenarios.
Reported-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Cc: <stable@vger.kernel.org> # 3.9.x+
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Commit 2c9f2365 (mtd: nand: omap: ecc.calculate: merge omap3_calculate_ecc_bch4
in omap_calculate_ecc_bch) introduced minor compile warning
"‘erased_sector_bitflips’ defined but not used [-Wunused-function]" when
compiling without CONFIG_MTD_NAND_OMAP_BCH. Move function
erased_sector_bitflips() into the same ifdef section as the only caller.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Reviewed-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use devm_ioremap_resource() in order to make the code simpler,
and remove redundant return value check of platform_get_resource()
because the value is checked by devm_ioremap_resource(). Also,
'unsigned long mem_size' is removed from 'struct omap_nand_info',
because the 'mem_size' variable is not necessary anymore.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

ELM hardware engine is used by BCH ecc-schemes for detecting and locating ECC
errors. This patch adds the following checks for ELM hardware engine:

 - ELM internal buffers are of 1K,
   so it cannot process data with ecc-step-size > 1K.

 - ELM engine can execute upto maximum of 8 threads in parallel,
   so in *page-mode* (when complete page is processed in single iteration),
   ELM cannot support ecc-steps > 8.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

'is_elm_present' flag is not used anywhere. This check is implicitely
taken care while selecting appropriate ecc-scheme via DT or board-file.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch
 - refactors GPMC configurations based on ecc-scheme
 - removed dependency on is_elm_present() flag, which is implicitely
   taken care by selecting appropriate ecc-scheme
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Lots of if..then..else conditions in omap_enable_hwecc_bch() can be avoided if
code is refactored based on ecc-scheme.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch
 - renames omap3_enable_hwecc_bch -> omap_enable_hwecc_bch to keep
   nomenclature independent of any device family.
 - using '__maybe_unused' instead of `ifdef based conditional compilation
   to suppress warning for un-used functions
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

merge omap3_calculate_ecc_bch8() into omap_calculate_ecc_bch() so that
common callback can be used for both OMAP_ECC_BCH8_CODE_HW and
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
+---------------------+-------------------------------------------------------+
|ecc-scheme           | nand_chip->calculate() after this patch               |
+---------------------+-------------------------------------------------------+
|HAM1_ECC             | omap_calculate_ecc()                                  |
+---------------------+-------------------------------------------------------+
|BCH4_HW_DETECTION_SW | omap_calculate_ecc_bch()                              |
|BCH4_HW              | omap_calculate_ecc_bch()                              |
|BCH8_HW_DETECTION_SW | omap3_calculate_ecc_bch8() -> omap_calculate_ecc_bch()|
|BCH8_HW              | omap_calculate_ecc_bch()                              |
+---------------------+-------------------------------------------------------+
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

merges omap3_calculate_ecc_bch4() into omap_calculate_ecc_bch() so that
common callback can be used for both OMAP_ECC_BCH4_CODE_HW and
OMAP_ECC_BCH4_CODE_HW_DETECTION_SW ecc-schemes

+---------------------+-------------------------------------------------------+
|ecc-scheme           | nand_chip->calculate() after this patch               |
+---------------------+-------------------------------------------------------+
|HAM1_ECC             | omap_calculate_ecc()                                  |
+---------------------+-------------------------------------------------------+
|BCH4_HW_DETECTION_SW | omap3_calculate_ecc_bch4() -> omap_calculate_ecc_bch()|
|BCH4_HW              | omap_calculate_ecc_bch()                              |
|BCH8_HW_DETECTION_SW | omap3_calculate_ecc_bch8()                            |
|BCH8_HW              | omap_calculate_ecc_bch()                              |
+---------------------+-------------------------------------------------------+
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

OMAP NAND driver supports multiple flavours of BCH4 and BCH8 ECC algorithms.
+------+------------------------------------+---------------+---------------+
| Algo | ECC scheme                         |ECC calculation|Error detection|
+------+------------------------------------+---------------+---------------+
|      |OMAP_ECC_BCH4_CODE_HW_DETECTION_SW  |H/W (GPMC)     |S/W            |
| BCH4 |OMAP_ECC_BCH4_CODE_HW               |H/W (GPMC)     |H/W (ELM)      |
+------+------------------------------------+---------------+---------------+
|      |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW  |H/W (GPMC)     |S/W            |
| BCH8 |OMAP_ECC_BCH8_CODE_HW               |H/W (GPMC)     |H/W (ELM)      |
+------+------------------------------------+---------------+---------------+

This patch refactors omap_calculate_ecc_bch() so that
 - separate out ecc-scheme specific code so that common-code can be reused
   between different implementations of same ECC algorithm.
 - new ecc-schemes can be added with ease in future.
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

rename omap3_calculate_ecc_bch -> omap_calculate_ecc_bch to
keep nomenclature independent of any device family.
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch updates following checks when bit-flips are detected by ELM:

 - Do not evaluate bit-flips when un-correctable bit-flips is reported by ELM,
   because as per [1] when ELM reports an un-correctable bit-flips,
   'number of error' field in its ELM_LOCATION_STATUS register is also invalid.

 - Return with error-code '-EBADMSG' on detection of un-correctable bit-flip.

 - Return with error-code '-EBADMSG' when bit-flips position is outside current
   Sector and OOB area.

[1] ELM IP spec Table-25 ELM_LOCATION_STATUS Register.
    ELM_LOCATION_STATUS[8] = ECC_CORRECTABLE: Error location process exit status
        0x0: ECC error location process failed.
             Number of errors and error locations are invalid.
        0x1: all errors were successfully located.
             Number of errors and error locations are valid.
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Current omap_elm_correct_data() code is not scalable for future ecc-schemes
due to presence of tweaks and hard-coded macros for BCH4_ECC and BCH8_ECC
ecc-schemes at multiple places.

This patch:
 - replaces 'ecc_opt' with '(info->nand.ecc.strength == BCH8_MAX_ERROR)
   used to differentiate between BCH8_HW and BCH4_SW
 - replaces macros (defining magic number for specific ecc-scheme) with
   generic variables
 - removes dependency on macros defined in elm.h (like BCHx_ECC_OOB_BYTES)
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

mtd: nand: omap: ecc.correct: omap_elm_correct_data: fix erased-page detection for BCHx_HW ECC schemes

As erased-pages do not have ECC stored in their OOB area, so they need to be
seperated out from programmed-pages, before doing BCH ECC correction.

In current implementation of omap_elm_correct_data() which does ECC correction
for BCHx ECC schemes, this erased-pages are detected based on specific marker
byte (reserved as 0x00) in ecc-layout.
However, this approach has some limitation like;
 1) All ecc-scheme layouts do not have such Reserved byte marker to
    differentiate between erased-page v/s programmed-page. Thus this is a
    customized solution.
 2) Reserved marker byte can itself be subjected to bit-flips causing
    erased-page to be misunderstood as programmed-page.

This patch removes dependency on any marker byte in ecc-layout, instead it
compares calc_ecc[] with pattern of ECC-of-all(0xff). This implicitely
means that both 'data + oob == all(0xff).
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

mtd: nand: omap: ecc.correct: omap_elm_correct_data: rename ambiguous variable 'eccsize' and 'ecc_vector_size'

renaming following variables as they cause confusion due to resemblence to
another similar field in 'struct nand_ecc_ctrl' (nand_chip->ecc.size).
renaming: ecc_vector_size --> ecc->bytes	(info->nand.ecc.bytes)
renaming: eccsize         --> actual_eccbytes	(info->nand.ecc.bytes - 1) for BCH4 and BCH8
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Information of currently selected ECC scheme 'enum omap_ecc ecc_opt' should
available outside platform-data, so that single nand_chip->ecc callback can
support multiple ecc-scheme configurations.
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch excludes reserved-marker byte-position from oobfree->length
calculation. Thus all bytes from oobfree->offset till end of OOB are free.

CC: <stable@vger.kernel.org> # 3.13.x+
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

1) In current implementation, ecclayout->oobfree->offset is calculated with
 respect to ecclayout->eccpos[0] which is incorrect because ECC bytes may not
 be stored contiguously in OOB.
 So, this patch calculates ecclayout->oobfree->offset with respect to last
 ECC byte-position 'eccpos[ecclayout->eccbytes-1]'.

2) ECC layout of some ecc-schemes expects reserved-markers at specific eccpos[]
 which should not be over-written by any file-system metadata.
 So this patch aligns oobfree->offset taking into account of such markers.

CC: <stable@vger.kernel.org> # 3.13.x+
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Fixes: commit a919e511
       mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW ECC configurations in device_probe

Fixes ecclayout mismatch introduced in above commit for following ecc-schemes:
 - OMAP_ECC_BCH4_CODE_HW_DETECTION_SW
 - OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
 However, this patch also touches other ecc-schemes as the fix required
 refactoring common code, into ecc-scheme specific code.

This patch aligns ecc-layout for below ecc-schemes as per reference [1],[2],[3]

 +---+------------+-------------++-------------+-------------+
 |OOB|BCH8_CODE_HW|BCH8_CODE_HW_||HAM1_CODE_HW |HAM1_CODE_HW |
 |pos|            | DETECTION_SW||(x8 device)  |(x16 device) |
 +---+------------+-------------++-------------+-------------+
 | 0 |BADBLK_MARK | BADBLK_MARK || BADBLK_MARK | BADBLK_MARK |
 | 1 |BADBLK_MARK | BADBLK_MARK || eccpos[0]   | BADBLK_MARK |
 | 2 | eccpos[0]  | eccpos[0]   || eccpos[1]   | eccpos[0]   |
 | 3 | eccpos[1]  | eccpos[1]   || eccpos[2]   | eccpos[1]   |
 | 4 | eccpos[2]  | eccpos[2]   || eccpos[3]   | eccpos[2]   |
 | 5 | eccpos[3]  | eccpos[3]   || eccpos[4]   | eccpos[3]   |
 | 6 | eccpos[4]  | eccpos[4]   || eccpos[5]   | eccpos[4]   |
 | 7 | eccpos[5]  | eccpos[5]   || eccpos[6]   | eccpos[5]   |
 | 8 | eccpos[6]  | eccpos[6]   || eccpos[7]   | eccpos[6]   |
 | 9 | eccpos[7]  | eccpos[7]   || eccpos[8]   | eccpos[7]   |
 |10 | eccpos[8]  | eccpos[8]   || eccpos[9]   | eccpos[8]   |
 |11 | eccpos[9]  | eccpos[9]   || eccpos[10]  | eccpos[9]   |
 |12 | eccpos[10] | eccpos[10]  || eccpos[11]  | eccpos[10]  |
 |13 | eccpos[11] | eccpos[11]  || oobfree[0]  | eccpos[11]  |
 |14 | eccpos[12] | eccpos[12]  || oobfree[1]  | oobfree[0]  |
 |15 | eccpos[13] | <reserved>  || oobfree[2]  | oobfree[1]  |
 +---+------------+-------------++-------------+-------------+
 |16 | eccpos[14] | eccpos[13]  || oobfree[3]  | oobfree[2]  |
 |...| [...]      | [...]       || [...]       | [...]       |
 |56 | eccpos[54] | eccpos[51]  || oobfree[43] | oobfree[42] |
 |57 | eccpos[55] | <reserved>  || oobfree[44] | oobfree[43] |
 +===+============+=============+==============+=============+
 |58 | oobfree[0] | oobfree[0]  || oobfree[45] | oobfree[44] |
 |59 | oobfree[1] | oobfree[1]  || oobfree[46] | oobfree[45] |
 |60 | oobfree[2] | oobfree[2]  || oobfree[47] | oobfree[46] |
 |61 | oobfree[3] | oobfree[3]  || oobfree[48] | oobfree[47] |
 |62 | oobfree[4] | oobfree[4]  || oobfree[49] | oobfree[48] |
 |63 | oobfree[5] | oobfree[5]  || oobfree[50] | oobfree[49] |
 +---+------------+-------------+--------------+-------------+

[1] ecc-layout expected by ROM code, as specified in SoC TRM under:
      Chapter="Initialization"
        Section="Device Initialization by ROM code"
            Sub-Section="Memory Booting"
                Heading="NAND"
                Figure="ECC Locations in NAND Spare Areas"

[2] ecc-layout updates in u-boot
    http://lists.denx.de/pipermail/u-boot/2013-November/167551.html

[3] u-boot configurations to match above ecc-layout are documented at
    https://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide

CC: <stable@vger.kernel.org> # 3.13.x+
Reported-by: NEnric Balletbo Serra <eballetbo@iseebcn.com>
Tested-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Tested-by: NStefan Roese <sr@denx.de>
Signed-off-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

The omap_{read,write}_buf{8,16}() functions are identical to the default
nand_base versions. Just let nand_base assign them in the
NAND_OMAP_POLLED case.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Tested-by: NPekon Gupta <pekon@ti.com>

Fix to return a negative error code from the error handling case instead
of 0, to more closely match the rest of this function.
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NPekon Gupta <pekon@ti.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

"Managed Device Resource" or devm_xx calls takes care of automatic freeing
of the resource in case of:
- failure during driver probe
- failure during resource allocation
- detaching or unloading of driver module (rmmod)
Reference: Documentation/driver-model/devres.txt

Though OMAP NAND driver handles freeing of resource allocation in most of
the cases, but using devm_xx provides more clean and effortless approach
to handle all such cases.

- simplifies label for exiting probe during error
  s/out_release_mem_region/return_error
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

generic frame-work in mtd/nand/nand_bch.c is a wrapper above lib/bch.h which
encapsulates all control information specific to BCH ecc algorithm in software.
Thus this patch:
(1) replace omap specific implementations with equivalent wrapper in nand_bch.c
    so that generic code from nand_bch.c is re-used. like;
        omap3_correct_data_bch() -> nand_bch_correct_data()
        omap3_free_bch() -> nand_bch_free()
(2) replace direct calls to lib/bch.c with wrapper functions defined in nand_bch.c
	init_bch() -> nand_bch_init()
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

In current implementation omap3_init_bch_tail() is a common function to
define ecc layout for different BCHx ecc schemes.This patch:
(1) removes omap3_init_bch_tail() and defines ecc layout for individual
    ecc-schemes along with populating their nand_chip->ecc data in
    omap_nand_probe(). This improves the readability and scalability of
    code for add new ecc schemes in future.
(2) removes 'struct nand_bbt_descr bb_descrip_flashbased' because default
    nand_bbt_descr in nand_bbt.c matches the same (.len=1 for x8 devices).
(3) add the check to see if NAND device has enough OOB/Spare bytes to
    store ECC signature of whole page, as defined by ecc-scheme.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

current implementation in omap3_init_bch() has some redundant code like:
(1) omap3_init_bch() re-probes the DT-binding to detect presence of ELM h/w
    engine on SoC. And based on that it selects implemetation of ecc-scheme.
    However, this is already done as part of GPMC DT parsing.
(2) As omap3_init_bch() serves as common function for configuring all types of
    BCHx ecc-schemes, so there are multiple levels of redudant if..then..else
    checks while populating nand_chip->ecc.

This patch make following changes to OMAP NAND driver:
(1) removes omap3_init_bch(): each ecc-scheme is individually configured in
    omap_nand_probe() there by removing redundant if..then..else checks.
(2) adds is_elm_present(): re-probing of ELM device via DT is not required as
    it's done in GPMC driver probe. Thus is_elm_present() just initializes ELM
    driver with NAND probe data, when ecc-scheme with h/w based error-detection
    is used.
(3) separates out configuration of different flavours of "BCH4" and "BCH8"
    ecc-schemes as given in below table
(4) conditionally compiles callbacks implementations of ecc.hwctl(),
    ecc.calculate(), ecc.correct() to avoid warning of un-used functions.

+---------------------------------------+---------------+---------------+
| ECC scheme                            |ECC calculation|Error detection|
+---------------------------------------+---------------+---------------+
|OMAP_ECC_HAM1_CODE_HW                  |H/W (GPMC)     |S/W            |
+---------------------------------------+---------------+---------------+
|OMAP_ECC_BCH4_CODE_HW_DETECTION_SW     |H/W (GPMC)     |S/W (lib/bch.c)|
| (needs CONFIG_MTD_NAND_ECC_BCH)       |               |               |
|                                       |               |               |
|OMAP_ECC_BCH4_CODE_HW                  |H/W (GPMC)     |H/W (ELM)      |
| (needs CONFIG_MTD_NAND_OMAP_BCH &&    |               |               |
|        ti,elm-id)                     |               |               |
+---------------------------------------+---------------+---------------+
|OMAP_ECC_BCH8_CODE_HW_DETECTION_SW     |H/W (GPMC)     |S/W (lib/bch.c)|
| (needs CONFIG_MTD_NAND_ECC_BCH)       |               |               |
|                                       |               |               |
|OMAP_ECC_BCH8_CODE_HW                  |H/W (GPMC)     |H/W (ELM)      |
| (needs CONFIG_MTD_NAND_OMAP_BCH &&    |               |               |
|        ti,elm-id)                     |               |               |
+---------------------------------------+---------------+---------------+

- 'CONFIG_MTD_NAND_ECC_BCH' is generic KConfig required to build lib/bch.c
    which is required for ECC error detection done in software.
    (mainly used for legacy platforms which do not have on-chip ELM engine)

- 'CONFIG_MTD_NAND_OMAP_BCH' is OMAP specific Kconfig to detemine presence
    on ELM h/w engine on SoC.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch:
- calls nand_scan_ident() using bus-width as passed by DT
- removes double calls to nand_scan_ident(), in case first call fails
  then omap_nand_probe just returns error.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

This patch updates following in omap_nand_probe() and omap_nand_remove()
- replaces "info->nand" with "nand_chip" (struct nand_chip *nand_chip)
- replaces "info->mtd" with "mtd" (struct mtd_info *mtd)
- white-space and formatting cleanup
Signed-off-by: NPekon Gupta <pekon@ti.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

OMAP NAND driver currently supports multiple flavours of 1-bit Hamming
ecc-scheme, like:
- OMAP_ECC_HAMMING_CODE_DEFAULT
	1-bit hamming ecc code using software library
- OMAP_ECC_HAMMING_CODE_HW
	1-bit hamming ecc-code using GPMC h/w engine
- OMAP_ECC_HAMMING_CODE_HW_ROMCODE
	1-bit hamming ecc-code using GPMC h/w engin with ecc-layout compatible
	to ROM code.

This patch combines above multiple ecc-schemes into single implementation:
- OMAP_ECC_HAM1_CODE_HW
	1-bit hamming ecc-code using GPMC h/w engine with ROM-code compatible
	ecc-layout.
Signed-off-by: NPekon Gupta <pekon@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

NAND_BBT_SCANEMPTY is a strange, badly-supported option with omap as its
single remaining user.

NAND_BBT_SCANEMPTY was likely used by accident in omap2[1]. And anyway,
omap2 doesn't scan the chip for bad blocks (courtesy of
NAND_SKIP_BBTSCAN), and so its use of this option is irrelevant.

This patch drops the NAND_BBT_SCANEMPTY option.

[1] http://lists.infradead.org/pipermail/linux-mtd/2012-July/042902.htmlSigned-off-by: NBrian Norris <computersforpeace@gmail.com>
Cc: Ivan Djelic <ivan.djelic@parrot.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

The driver core clears the driver data to NULL after device_release
or on probe failure, since commit 0998d063
(device-core: Ensure drvdata = NULL when no driver is bound).
Thus, it is not needed to manually clear the device driver data to NULL.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Fix mtd-utils from returning -EIO. Formatting jffs2 filesystem was impossible
when CONFIG_HZ was set to a low value.
Signed-off-by: NToan Pham <tpham3783@gmail.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

In case the driver is not probed - due to config mismatches or errors
in the DTS files - dev_get_drvdata() returns NULL, leading to an Ooops
during boot.

Make elm_config() return an error in such cases to propagate the error
up to the user, so it can fall back to software mode.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

ELM module can be used for hardware error correction of BCH 4 & 8 bit.
ELM module functionality is verified by checking the availability of
handle for ELM module in device tree. Hence supporting
1. ELM module available, BCH error correction done by ELM module. Also
support read & write page in one shot by adding custom read_page and
write_page methods. This helps in optimizing code for NAND flashes with
page size less than 4 KB.
2. If ELM module not available fall back to software BCH error
correction support.

New structure member is added to omap_nand_info
1. "is_elm_used" to know the status of whether the ELM module is used for
   error correction or not.
2. "elm_dev" device pointer to elm device on detection of ELM module.

Also being here update the device tree documentation of gpmc-nand for
adding optional property elm_id.

Note:
ECC layout uses 1 extra bytes for 512 byte of data to handle erased
pages. Extra byte programmed to zero for programmed pages. Also BCH8
requires 14 byte ecc to maintain compatibility with RBL ECC layout.
This results a common ecc layout across RBL, U-boot & Linux with BCH8.
Signed-off-by: NPhilip Avinash <avinashphilip@ti.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Remove check of ecc bytes with 13, number of errors can directly update
from nand ecc strength. This will increase re-usability of the code.
Also add macro definitions BCH8_ERROR_MAX & BCH4_ERROR_MAX for better
readability and cleaner code.
Signed-off-by: NPhilip Avinash <avinashphilip@ti.com>
Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>

Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.

For non-DT boards, this change has no effect.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NArtem Bityutskiy <dedekind1@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>