summaryrefslogtreecommitdiff
path: root/drivers/mtd/nand/omap_gpmc.c
Commit message (Collapse)AuthorAgeLines
* armv7: make gpmc_cfg constLadislav Michl2016-07-22-1/+2
| | | | | | | | Signed-off-by: Ladislav Michl <ladis@linux-mips.org> [trini: Adapt am33xx, duovero, omap_zoom1] Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* mtd: nand: omap: allow to switch to BCH16Heiko Schocher2016-06-09-0/+4
| | | | | | | support in omap_nand_switch_ecc() also an eccstrength from 16. Signed-off-by: Heiko Schocher <hs@denx.de>
* mtd: nand: Sync with Linux v4.6Scott Wood2016-06-03-1/+1
| | | | | | | | | | | | Updates the NAND code to match Linux v4.6. The previous sync was from Linux v4.1 in commit d3963721d93fafa. Note that none of the individual NAND drivers tracked Linux closely enough to be synced themselves, other than manually applying a few cross-tree changes. Signed-off-by: Scott Wood <oss@buserror.net> Tested-by: Heiko Schocher <hs@denx.de>
* mtd: nand: Add+use mtd_to/from_nand and nand_get/set_controller_dataScott Wood2016-06-03-20/+20
| | | | | | | | | These functions are part of the Linux 4.6 sync. They are being added before the main sync patch in order to make it easier to address the issue across all NAND drivers (many/most of which do not closely track their Linux counterparts) separately from other merge issues. Signed-off-by: Scott Wood <oss@buserror.net>
* nand: Embed mtd_info in struct nand_chipScott Wood2016-06-03-2/+2
| | | | | | | | | | | | nand_info[] is now an array of pointers, with the actual mtd_info instance embedded in struct nand_chip. This is in preparation for syncing the NAND code with Linux 4.6, which makes the same change to struct nand_chip. It's in a separate commit due to the large amount of changes required to accommodate the change to nand_info[]. Signed-off-by: Scott Wood <oss@buserror.net>
* Fix spelling of "occurred".Vagrant Cascadian2016-05-02-2/+2
| | | | | Signed-off-by: Vagrant Cascadian <vagrant@debian.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* nand: omap_gpmc: Change correctable bit-flips messages to debug()Ezequiel García2015-10-11-3/+3
| | | | | | | | Messages on corrected bit-flips are not really useful, as bit-flips are perfectly normal. Let's avoid cluttering the console and make them debug. Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
* mtd: OMAP: Enable GPMC prefetch mode for 16 bit accessJeroen Hofstee2015-06-18-10/+18
| | | | | | | | | | | | commit c316f57 "mtd: OMAP: Enable GPMC prefetch mode" only enabled prefetch mode for 8 bit nand access, this adds 16 bit as well. Cc: Scott Wood <scottwood@freescale.com> Cc: Tom Rini <trini@konsulko.com> Cc: Daniel Mack <zonque@gmail.com> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> Reviewed-by: Tom Rini <trini@konsulko.com>
* omap_gpmc: move prefetch out of CONFIG_NAND_OMAP_ELMJeroen Hofstee2015-06-18-109/+109
| | | | | | | | | | | | | The prefech mode is a feature of the gpmc, not the ELM. An am3517 does not have an elm, but can do prefeches, so move the code out of the CONFIG_NAND_OMAP_ELM ifdef. Cc: Scott Wood <scottwood@freescale.com> Cc: Tom Rini <trini@konsulko.com> Cc: Daniel Mack <zonque@gmail.com> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> Reviewed-by: Tom Rini <trini@konsulko.com>
* omap: gpmc: 'nandecc sw' can use HAM1 or BCH8Ash Charles2015-03-05-1/+11
| | | | | | | | | | | | | | | The 'nandecc sw' command selects a software-based error correction algorithm. By default, this is OMAP_ECC_HAM1_CODE_SW but some platforms use OMAP_ECC_BCH8_CODE_HW_DETECTION_SW as their software-based correction algorithm. Allow a user to be specific e.g. # nandecc sw <hamming|bch8> where 'hamming' is still the default. Note: we don't just use CONFIG_NAND_OMAP_ECCSCHEME as it might be set to a hardware-based ECC scheme---a little strange when the user has requested 'sw' ECC. Signed-off-by: Ash Charles <ashcharles@gmail.com>
* mtd: nand: omap_gpmc: Make ready/busy pins configurableMichal Sojka2015-03-05-2/+14
| | | | | | | | | | | | | | | | | | | | | | | Commit fb384c4720ca7496775d6578f184bf628db73456 introduced the use of WAIT0 pin for determining whether the NAND is ready or not. This only works if all NAND chips are connected to WAIT0. If some chips are connected to the other available pin WAIT1, nand_wait() does not really wait and prints a WARN_ON message. This patch allows the board to provide configuration of which chip is connected to which WAITx signal. For example, one can define in include/configs/foo.h: #define CONFIG_NAND_OMAP_GPMC_WSCFG 0,0,1,1 This would mean that chips using to CS0 and 1 are connected to WAIT0 and chips with CS2 and 3 are connected to WAIT1. Signed-off-by: Michal Sojka <sojka@merica.cz> Acked-by: Stefan Roese <sr@denx.de> Tested-by: Michal Vokáč <michal.vokac@comap.cz> Cc: Tom Rini <trini@ti.com>
* mtd, omap: fix case NAND_OMAP_GPMC_PREFETCH not definedEgli, Samuel2015-02-16-1/+4
| | | | | | | | | | | | | | | | The patch c316f577b4b72d1a1aeb559e9b3fad20808f1ffd breaks siemens boards because prefetch mode is not enabled. I assume it breaks other boards as well that don't use prefetch. This patch sets read_buf to nand_read_buf if NAND_OMAP_GPMC_PREFETCH is not defined. Signed-off-by: Samuel Egli <samuel.egli@siemens.com> CC: Daniel Mack <zonque@gmail.com> CC: Guido Martínez <guido@vanguardiasur.com.ar> CC: Tom Rini <trini@ti.com> CC: Heiko Schocher <hs@denx.de>
* mtd: OMAP: Enable GPMC prefetch modeDaniel Mack2015-01-13-2/+112
| | | | | | | | | | | | | | | | | | | | | | | | | Enable GPMC's prefetch feature for NAND access. This speeds up NAND read access a lot by pre-fetching contents in the background and reading them through the FIFO address. The current implementation has two limitations: a) it only works in 8-bit mode b) it only supports read access Both is easily fixable by someone who has hardware to implement it. Note that U-Boot code uses non word-aligned buffers to read data into, and request read lengths that are not multiples of 4, so both partial buffers (head and tail) have to be addressed. Tested on AM335x hardware. Tested-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: Guido Martínez <guido@vanguardiasur.com.ar> Signed-off-by: Daniel Mack <zonque@gmail.com> [trini: Make apply again, use 'cs' fix pointed out by Guido] Signed-off-by: Tom Rini <trini@ti.com>
* mtd: nand: omap_gpmc: fix error handlingGuido Martínez2015-01-05-1/+2
| | | | | | | | | | | | "err" was an unsigned variable, causing negative error codes to turn into positive values, which are interpreted as an amount of succesfully corrected bitflips (and thus not an error). In particular, this resulted in that if the elm reports uncorrectable errors (-EBADMSG), the MTD layer (and UBI) falsely succeeded. Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_gpmc: Always use ready/busy pinStefan Roese2014-12-04-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The functions to detect the state of the ready / busy signal is already available but only used in the SPL case. Lets use it always, also for the main U-Boot. As all boards should have this HW connection. Testing on Siemens Draco (am335x) showed a small perfomance gain by using this ready pin to detect the NAND chip state. Here the values tested on Draco with Hynix 4GBit NAND: Without NAND ready pin: U-Boot# time nand read 80400000 0 400000 NAND read: device 0 offset 0x0, size 0x400000 4194304 bytes read: OK time: 2.947 seconds, 2947 ticks With NAND ready pin: U-Boot# time nand read 80400000 0 400000 NAND read: device 0 offset 0x0, size 0x400000 4194304 bytes read: OK time: 2.795 seconds, 2795 ticks So an increase of approx. 5%. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Samuel Egli <samuel.egli@siemens.com>
* omap_gpmc: fix warnigs with W=1Jeroen Hofstee2014-10-25-18/+18
| | | | | | | | - make omap_spl_dev_ready static - make omap_reverse_list static, move to under CONFIG_NAND_OMAP_ELM Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl> Signed-off-by: Tom Rini <trini@ti.com>
* mtd: nand: omap_gpmc: Fix 'bit-flip' errorsRostislav Lisovy2014-09-04-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | OMAP GPMC driver used with some NAND Flash devices (e.g. Spansion S34ML08G1) causes that U-boot shows hundreds of 'nand: bit-flip corrected' error messages. Possible cause was discussed in the mailinglist thread: http://lists.denx.de/pipermail/u-boot/2014-April/177508.html Quote (Author: Pekon Gupta <pekon@ti.com>): "The issue is mainly due to a NAND protocol violation in the omap driver since the Random Data Output command (05h-E0h) expects to see only the column address that should be addressed within the already loaded read page into the read buffer. Only 2 address cycles with ALE active should be provided between the 05h and E0h commands. The Page read command expects the full address footprint (2bytes for column address + 3bytes for row address), but once the page is loaded into the read buffer, Random Data Output should be used with only 2bytes for column address." This patch combines the solution proposed in the mailinglist and the patch provided by the Spansion company (GPLv2 code, source: http://www.spansion.com/Support/Software/u-boot-psp-04.04.00.01-NAND.zip) Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
* mtd: nand: omap_gpmc: Enable multiple NAND flash devicesRostislav Lisovy2014-09-04-22/+20
| | | | | | | | | | | Since the CS of a device connected to the GPMC was stored in the global variable, it was not possible to use multiple devices. In this patch the CS is stored per device in its 'struct omap_nand_info'. This makes it possible to use up to 'GPMC_MAX_CS' NAND Flash devices connected to U-boot. Signed-off-by: Rostislav Lisovy <lisovy@merica.cz>
* mtd: nand: omap: add support for BCH16_ECC - NAND driver updatespekon gupta2014-06-06-1/+78
| | | | | | | | | | | | | | | | | | This patch add support for BCH16_ECC to omap_gpmc driver. *need to BCH16 ECC scheme* With newer SLC Flash technologies and MLC NAND, and large densities, pagesizes Flash devices have become more suspectible to bit-flips. Thus stronger ECC schemes are required for protecting the data. But stronger ECC schemes have come with larger-sized ECC syndromes which require more space in OOB/Spare. This puts constrains like; (a) BCH16_ECC can correct 16 bit-flips per 512Bytes of data. (b) BCH16_ECC 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 following equation: OOBsize per page >= 26 * (page-size / 512) Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device ↵pekon gupta2014-06-06-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | bus-width GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization. Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working. This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals. Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: fix error-codes returned from omap-elm driverpekon gupta2014-06-06-4/+4
| | | | | | | | | | | This patch omap-elm.c: replaces -ve integer value returned during errorneous condition, with proper error-codes. omap-gpmc.c: updates omap-gpmc driver to pass error-codes returned from omap-elm driver to upper layers Signed-off-by: Pekon Gupta <pekon@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_gpmc: minor cleanup of omap_correct_data_bchpekon gupta2014-06-06-5/+5
| | | | | | | | This patch tries to avoid some local pointer dereferences, by using common local variables in omap_correct_data_bch() Signed-off-by: Pekon Gupta <pekon@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_gpmc: rename struct nand_bch_priv to struct omap_nand_infopekon gupta2014-06-06-32/+26
| | | | | | | | | This patch renames 'struct nand_bch_priv' which currently holds private data only for BCH ECC schemes, into 'struct omap_nand_info' so that same can be used for all ECC schemes Signed-off-by: Pekon Gupta <pekon@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_gpmc: remove unused members of 'struct nand_bch_priv'pekon gupta2014-06-06-17/+6
| | | | | | | | | | This patch prepares to refactor 'struct nand_bch_priv' -> 'struct omap_nand_info' And thus performs following clean-ups: - remove nand_bch_priv.type: use nand_bch_priv.ecc_scheme instead - remove nand_bch_priv.mode: <unused> Signed-off-by: Pekon Gupta <pekon@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_elm: use bch_type instead of nibble count to differentiate ↵pekon gupta2014-06-06-8/+2
| | | | | | | | | | | | | | | | | | | between BCH4/BCH8/BCH16 ELM hardware engine support ECC error detection for multiple ECC strengths like +------+------------------------+ |Type | ECC syndrome length | +------+------------------------+ |BCH4 | 6.5 bytes = 13 nibbles | |BCH8 | 13 byte = 26 nibbles | |BCH16 | 26 bytes = 52 nibbles | +------+------------------------+ Current implementation of omap_elm driver uses ECC syndrom length (in 'nibbles') to differentiate between BCH4/BCH8/BCH16. This patch replaces it with 'bch_type' Signed-off-by: Pekon Gupta <pekon@ti.com> Reviewed-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap_gpmc: Fix update of read_ecc in oobBelisko Marek2014-05-13-1/+1
| | | | | | | We need to flip only one bit not assign. Signed-off-by: Marek Belisko <marek.belisko@gmail.com> Acked-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: move omap_elm.h from arch/arm/include/asm to drivers/mtd/nandpekon gupta2014-03-04-1/+1
| | | | | | | | | omap_elm.h is a generic header used by OMAP ELM driver for all TI platfoms. Hence this file should be present in generic folder instead of architecture specific include folder. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: move omap_gpmc.h from arch/arm/include/asm to drivers/mtd/nandpekon gupta2014-03-04-1/+1
| | | | | | | | | omap_gpmc.h is a generic header used by OMAP NAND driver for all TI platfoms. Hence this file should be present in generic folder instead of architecture specific include folder. Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: merge duplicate GPMC data from different arch-xx headers ↵pekon gupta2014-03-04-1/+0
| | | | | | | | | | | | | | | into common omap_gpmc.h Each SoC platform (AM33xx, OMAP3, OMAP4, OMAP5) has its own copy of GPMC related defines and declarations scattered in SoC platform specific header files like include/asm/arch-xx/cpu.h However, GPMC hardware remains same across all platforms thus this patch merges GPMC data scattered across different arch-xx specific header files into single header file include/asm/arch/omap_gpmc.h Build tested using: ./MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: optimized chip->ecc.correct() for H/W ECC schemespekon gupta2014-03-03-90/+71
| | | | | | | | | | | | | | | | | | | chip->ecc.correct() is used for detecting and correcting bit-flips during read operations. In omap-nand driver it implemented as: (a) omap_correct_data(): for h/w based ECC_HAM1 scheme (b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW for ECC_BCH8 scheme using GPMC and software lib/bch.c (c) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW for ECC_BCH8 scheme using GPMC and ELM This patch updates (c) - checks for calc_ecc[]==0x00 so that error_correction is not required for known good pages. - adds scalability for other ECC_BCHx scheme by merging following omap_rotate_ecc_bch() + omap_fix_errors_bch() => omap_correct_data_bch() - fixing logic for bit-flip correction based on error_loc[count] Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: optimize chip->ecc.calculate() for H/W ECC schemespekon gupta2014-03-03-163/+63
| | | | | | | | | | | | | | | | | chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by processing the data passed during Read/Write accesses. All H/W based ECC schemes use GPMC controller to calculate ECC syndrome. But each BCHx_ECC scheme has its own implemetation of post-processing and fetching ECC syndrome from GPMC controller. This patch updates OMAP_ECC_BCH8_CODE_HW ECC scheme in following way: - merges multiple chip->calculate API for different ECC schemes omap_calculate_ecc() + omap_calculate_ecc_bch() + omap_calculate_ecc_bch_sw() ==> omap_calculate_ecc() - removes omap_ecc_disable() and instead uses it as inline. Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: optimize chip->ecc.hwctl() for H/W ECC schemespekon gupta2014-03-03-142/+56
| | | | | | | | | | | | | | | | | | | chip->ecc.hwctl() is used for preparing the H/W controller before read/write NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.) Though all ECC schemes in OMAP NAND driver use GPMC controller for generating ECC syndrome (for both Read/Write accesses). But but in current code HAM1_ECC and BCHx_ECC schemes implement individual function to achieve this. This patch (1) removes omap_hwecc_init() and omap_hwecc_init_bch() as chip->ecc.hwctl will re-initializeGPMC before every read/write call. omap_hwecc_init_bch() -> omap_enable_ecc_bch() (2) merges the GPMC configuration code for all ECC schemes into single omap_enable_hwecc(), thus adding scalability for future ECC schemes. omap_enable_hwecc() + omap_enable_ecc_bch() -> omap_enable_hwecc() Signed-off-by: Pekon Gupta <pekon@ti.com>
* nand, gpmc: fix reading after switching eccJeroen Hofstee2014-01-17-0/+1
| | | | | | | | | | | | | | The omap_gpmc allows switching ecc at runtime. Since the NAND_SUBPAGE_READ flag is only set, it is kept when switching to hw ecc, which is not correct. This leads to calling chip->ecc.read_subpage which is not a valid pointer. Therefore clear the flag when switching ecc so reading in hw mode works again. Cc: Scott Wood <scottwood@freescale.com> Cc: Pekon Gupta <pekon@ti.com> Cc: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
* mtd: nand: omap: fix ecc ops assignment when changing eccNikita Kiryanov2013-12-17-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | If we change to software ecc and then back to hardware ecc, the nand ecc ops pointers are populated with incorrect function pointers. This is related to the way nand_scan_tail() handles assigning functions to ecc ops: If we are switching to software ecc/no ecc, it assigns default functions to the ecc ops pointers unconditionally, but if we are switching to hardware ecc, the default hardware ecc functions are assigned to ops pointers only if these pointers are NULL (so that drivers could set their own functions). In the case of omap_gpmc.c driver, when we switch to sw ecc, sw ecc functions are assigned to ecc ops by nand_scan_tail(), and when we later switch to hw ecc, the ecc ops pointers are not NULL, so nand_scan_tail() does not overwrite them with hw ecc functions. The result: sw ecc functions used to write hw ecc data. Clear the ecc ops pointers in omap_gpmc.c when switching ecc types, so that ops which were not assigned by the driver will get the correct default values from nand_scan_tail(). Cc: Scott Wood <scottwood@freescale.com> Cc: Pekon Gupta <pekon@ti.com> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
* mtd: nand: omap: fix sw->hw->sw ecc switchNikita Kiryanov2013-12-17-1/+6
| | | | | | | | | | | | | | | | | | | | | | When switching ecc mode, omap_select_ecc_scheme() assigns the appropriate values into the current nand chip's ecc.layout struct. This is done under the assumption that the struct exists only to store values, so it is OK to overwrite it, but there is at least one situation where this assumption is incorrect: When switching to 1 bit hamming code sw ecc, the job of assigning layout data is outsourced to nand_scan_tail(), which simply assigns into ecc.layout a pointer to an existing struct prefilled with the appropriate values. This struct doubles as both data and layout definition, and therefore shouldn't be overwritten, but on the next switch to hardware ecc, this is exactly what's going to happen. The next time the user switches to software ecc, they're going to get a messed up ecc layout. Prevent this and possible similar bugs by explicitly using the private-to-omap_gpmc.c omap_ecclayout struct when switching ecc mode. Cc: Scott Wood <scottwood@freescale.com> Cc: Pekon Gupta <pekon@ti.com> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il>
* mtd: nand: omap: fix HAM1_SW ecc using default value for ecc.sizeNikita Kiryanov2013-12-17-1/+1
| | | | | | | | | | | | | | | | | | | | | | Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic platform" (d016dc42cedbf6102e100fa9ecb58462edfb14f8) changed the way software ECC is configured, both during boot, and during ecc switch, in a way that is not backwards compatible with older systems: Older version of omap_gpmc.c always assigned ecc.size = 0 when configuring for software ecc, relying on nand_scan_tail() to select a default for ecc.size (256), while the new version of omap_gpmc.c assigns ecc.size = pagesize, which is likely to not be 256. Since 1 bit hamming sw ecc is only meant to be used by legacy devices, revert to the original behavior. Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Tom Rini <trini@ti.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Pekon Gupta <pekon@ti.com> Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Acked-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap_gpmc: cosmetic: Fix indentationStefan Roese2013-12-17-43/+45
| | | | | | | | Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pekon Gupta <pekon@ti.com> Cc: Scott Wood <scottwood@freescale.com> [scottwood@freescale.com: wrap some long lines] Signed-off-by: Scott Wood <scottwood@freescale.com>
* mtd: nand: omap: fix ecc-layout for HAM1 ecc-schemepekon gupta2013-12-17-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per OMAP3530 TRM referenced below [1] For large-page NAND, ROM code expects following ecc-layout for HAM1 ecc-scheme - OOB[1] (offset of 1 *byte* from start of OOB) for x8 NAND device - OOB[2] (offset of 1 *word* from start of OOB) for x16 NAND device Thus ecc-layout expected by ROM code for HAM1 ecc-scheme is: *for x8 NAND Device* +--------+---------+---------+---------+---------+---------+---------+ | xxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] | ... +--------+---------+---------+---------+---------+---------+---------+ *for x16 NAND Device* +--------+--------+---------+---------+---------+---------+---------+---------+ | xxxxx | xxxxx | ECC[A0] | ECC[A1] | ECC[A2] | ECC[B0] | ECC[B1] | ECC[B2] | +--------+--------+---------+---------+---------+---------+---------+---------+ This patch fixes ecc-layout *only* for HAM1, as required by ROM-code For other ecc-schemes like (BCH8) ecc-layout is same for x8 or x16 devices. [1] OMAP3530: http://www.ti.com/product/omap3530 TRM: http://www.ti.com/litv/pdf/spruf98x Chapter-25: Initialization Sub-topic: Memory Booting Section: 25.4.7.4 NAND Figure 25-19. ECC Locations in NAND Spare Areas Reported-by: Stefan Roese <sr@denx.de> Signed-off-by: Pekon Gupta <pekon@ti.com> Tested-by: Stefan Roese <sr@denx.de>
* mtd: nand: omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-schemepekon gupta2013-11-21-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed CONFIG_xx used for selecting NAND ecc-schemes. This patch aims at solving following issues. 1) Currently ecc-scheme is tied to SoC platform, which prevents user to select other ecc-schemes also supported in hardware. like; - most of OMAP3 SoC platforms use only 1-bit Hamming ecc-scheme, inspite the fact that they can use higher ecc-schemes like 8-bit ecc-schemes with software based error detection (OMAP_ECC_BCH4_CODE_HW_DETECTION_SW). - most of AM33xx SoC plaforms use 8-bit BCH ecc-scheme for now, but hardware supports BCH16 ecc-scheme also. 2) Different platforms use different CONFIG_xx to select ecc-schemes, which adds confusion for user while migrating platforms. - *CONFIG_NAND_OMAP_ELM* which enables ELM hardware engine, selects only 8-bit BCH ecc-scheme with h/w based error-correction (OMAP_ECC_BCH8_CODE_HW) whereas ELM hardware engine supports other ecc-schemes also like; BCH4, and BCH16 (in future). - *CONFIG_NAND_OMAP_BCH8* selects 8-bit BCH ecc-scheme with s/w based error correction (OMAP_ECC_BCH8_CODE_HW_DETECTION_SW). - *CONFIG_SPL_NAND_SOFTECC* selects 1-bit Hamming ecc-scheme using s/w library Thus adding new *CONFIG_NAND_OMAP_ECCSCHEME* de-couples ecc-scheme dependency on SoC platform and NAND driver. And user can select ecc-scheme independently foreach board. However, selection some hardware based ecc-schemes (OMAP_ECC_BCHx_CODE_HW) still depends on presence of ELM hardware engine on SoC. (Refer doc/README.nand) Signed-off-by: Pekon Gupta <pekon@ti.com>
* mtd: nand: omap: enable BCH ECC scheme using ELM for generic platformpekon gupta2013-11-21-125/+201
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours +-----------------------------------+-----------------+-----------------+ |ECC Scheme | ECC Calculation | Error Detection | +-----------------------------------+-----------------+-----------------+ |OMAP_ECC_BCH8_CODE_HW |GPMC |ELM H/W engine | |OMAP_ECC_BCH8_CODE_HW_DETECTION_SW |GPMC |S/W BCH library | +-----------------------------------+-----------------+-----------------+ Current implementation limits the BCH8_CODE_HW only for AM33xx device family. (using CONFIG_AM33XX). However, other SoC families (like TI81xx) also have ELM hardware module, and can support ECC error detection using ELM. This patch - removes CONFIG_AM33xx Thus this driver can be reused by all devices having ELM h/w engine. - adds omap_select_ecc_scheme() A common function to handle ecc-scheme related configurations. This can be used both during device-probe and via user-space u-boot commads to change ecc-scheme. During device probe ecc-scheme is selected based on CONFIG_NAND_OMAP_ELM or CONFIG_NAND_OMAP_BCH8 - enables CONFIG_BCH S/W library (lib/bch.c) required by OMAP_ECC_BCHx_CODE_HW_DETECTION_SW is enabled by CONFIG_BCH. - enables CONFIG_SYS_NAND_ONFI_DETECTION for auto-detection of ONFI compliant NAND devices - updates following README doc doc/README.nand board/ti/am335x/README doc/README.omap3 Signed-off-by: Pekon Gupta <pekon@ti.com> [scottwood@freescale.com: fixed unused variable warning] Signed-off-by: Scott Wood <scottwood@freescale.com>
* mtd: nand: omap: make am33xx/elm.c as common driver for all OMAPx and AMxxxx ↵pekon gupta2013-11-21-1/+1
| | | | | | | | | | | | | | | | | | platforms ELM hardware engine which is used for ECC error detection, is present on all latest OMAP SoC (like OMAP4xxx, OMAP5xxx, DRA7xxx, AM33xx, AM43xx). Thus ELM driver should be moved to common drivers/mtd/nand/ folder so that all SoC having on-chip ELM hardware engine can re-use it. This patch has following changes: - mv arch/arm/include/asm/arch-am33xx/elm.h arch/arm/include/asm/omap_elm.h - mv arch/arm/cpu/armv7/am33xx/elm.c drivers/mtd/nand/omap_elm.c - update Makefiles - update #include <asm/elm.h> - add CONFIG_NAND_OMAP_ELM to compile driver/mtd/nand/omap_elm.c and include in all board configs using AM33xx SoC platform. Signed-off-by: Pekon Gupta <pekon@ti.com>
* Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk2013-07-24-17/+1
| | | | | | Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
* bug, nand, am33xx: nand->ecc.strength not set in board_nand_init()Sergey Lapin2013-06-04-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | commit dfe64e2c89731a3f9950d7acd8681b68df2bae03 Author: Sergey Lapin <slapin@ossfans.org> Date: Mon Jan 14 03:46:50 2013 +0000 mtd: resync with Linux-3.7.1 Introduced runtime bug: U-Boot 2013.04-00499-g46567df-dirty (Jun 04 2013 - 08:17:08) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: BUG: failure at nand_base.c:3214/nand_scan_tail()! BUG! resetting ... on boards using drivers/mtd/nand/omap_gpmc.c as in board_nand_init() nand->ecc.strength is not set. Fix this! Signed-off-by: Heiko Schocher <hs@denx.de> Cc: Sergey Lapin <slapin@ossfans.org> Cc: Scott Wood <scottwood@freescale.com> Cc: Tom Rini <trini@ti.com>
* mtd: resync with Linux-3.7.1Sergey Lapin2013-05-31-2/+4
| | | | | | | | | | | | | | | | | | | | | | This patch is essentially an update of u-boot MTD subsystem to the state of Linux-3.7.1 with exclusion of some bits: - the update is concentrated on NAND, no onenand or CFI/NOR/SPI flashes interfaces are updated EXCEPT for API changes. - new large NAND chips support is there, though some updates have got in Linux-3.8.-rc1, (which will follow on top of this patch). To produce this update I used tag v3.7.1 of linux-stable repository. The update was made using application of relevant patches, with changes relevant to U-Boot-only stuff sticked together to keep bisectability. Then all changes were grouped together to this patch. Signed-off-by: Sergey Lapin <slapin@ossfans.org> [scottwood@freescale.com: some eccstrength and build fixes] Signed-off-by: Scott Wood <scottwood@freescale.com>
* omap_gpmc: add support for hw assisted BCH8Andreas Bießmann2013-04-08-91/+276
| | | | | | | | | | | | | | | | | | | | | | The kernel states: ---8<--- The OMAP3 GPMC hardware BCH engine computes remainder polynomials, it does not provide automatic error location and correction: this step is implemented using the BCH library. --->8--- And we do so in u-boot. This implementation uses the same layout for BCH8 but it is fix. The current provided layout does only work with 64 Byte OOB. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Ilya Yanok <ilya.yanok@cogentembedded.com> Cc: Scott Wood <scottwood@freescale.com> Cc: Mansoor Ahamed <mansoor.ahamed@ti.com> Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
* omap_gpmc: change nandecc commandAndreas Bießmann2013-04-08-26/+31
| | | | | | | | | | | | | With uppcoming BCH support on OMAP devices we need to decide between differnt algorithms when switching the ECC engine. Currently we support 1-bit hammign and 8-bit BCH on HW backend. In order to switch between differnet ECC algorithms we need to change the interface of omap_nand_switch_ecc() also. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Cc: Thomas Weber <thomas.weber.linux@googlemail.com>
* asm/omap_gpmc.h: consolidate common definesAndreas Bießmann2013-04-08-1/+1
| | | | | | | | | | | | | arch/arm/include/asm/arch-am33xx/omap_gpmc.h and arch/arm/include/asm/arch-omap3/omap_gpmc.h are almost the same, consolidate the common parts into a new header. Introduce a new asm/omap_gpmc.h which defines the command part and pulls in the architecture specific one. Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Tom Rini <trini@ti.com> Reviewed-by: Tom Rini <trini@ti.com>
* am33xx: Add required includes to some omap/am33xx codeTom Rini2013-03-24-0/+1
| | | | | | | | | | | | | - In arch/arm/cpu/armv7/omap-common/timer.c, drivers/mtd/nand/omap_gpmc.c and drivers/net/cpsw.c add #include files that the driver needs but had been relying on <config.h> to bring in. - In arch/arm/cpu/armv7/omap-common/lowlevel_init.S add <config.h> - In am335x_evm.h and pcm051.h don't globally include <asm/arch/hardware.h> and <asm/arch/cpu.h> but just <asm/arch/omap.h> as that is the only include which defines things the config uses. Cc: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: Tom Rini <trini@ti.com>
* omap_gpmc: BCH8 support (ELM based)Mansoor Ahamed2012-12-10-1/+402
| | | | | | | | | | This patch adds support for BCH8 error correction code to omap_gpmc driver. We use GPMC to generate codes/syndromes but we need ELM to find error locations from given syndrome. Signed-off-by: Mansoor Ahamed <mansoor.ahamed@ti.com> [ilya: merge it with omap_gpmc driver, some fixes and cleanup] Signed-off-by: Ilya Yanok <ilya.yanok@cogentembedded.com>
* arm: omap: Fix switching back to nandecc sw.Jeroen Hofstee2012-09-01-0/+1
| | | | | | | | | | | | | | | | | | | | | | Orjan Friberg wrote at [1]: "For the beagleboard, ecc.size is not explicitly set when doing 'nandecc sw'. If it's not set for the NAND_ECC_SOFT case in nand_scan_tail, it's set to 256 bytes. When doing 'nandecc hw', ecc.size is set to 512 bytes. Hence, when changing back to 'nandecc sw' ecc.size remains at 512 bytes and suddenly the format has changed." No patch has been submitted and the issue was still present. This patch adds the mentioned solution. Tested on a tam3517 board. [1] http://lists.denx.de/pipermail/u-boot/2012-February/119002.html cc: Orjan Friberg <of@flatfrog.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Acked-by: Nikita Kiryanov <nikita@compulab.co.il> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com>
generated by cgit v1.1 at 2024-11-07 16:51:29 +0000