1. 09 Jan, 2014 1 commit
  2. 31 Dec, 2013 1 commit
    • Marek Vasut's avatar
      mtd: onenand: Fix unaligned access · 9b56942f
      Marek Vasut authored
      
      
      Fix unaligned access in OneNAND core. The problem is that the ffchars[] array
      is an array of "unsigned char", but in onenand_write_ops_nolock() can be passed
      to the memcpy_16() function. The memcpy_16() function will treat the buffer as
      an array of "unsigned short", thus triggering unaligned access if the compiler
      decided ffchars[] to be not aligned.
      
      I managed to trigger the problem with regular ELDK 5.4 GCC compiler.
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Albert Aribaud <albert.u.boot@aribaud.net>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Tom Rini <trini@ti.com>
      9b56942f
  3. 19 Dec, 2013 1 commit
  4. 18 Dec, 2013 12 commits
  5. 17 Dec, 2013 6 commits
    • Nikita Kiryanov's avatar
      mtd: nand: omap: fix ecc ops assignment when changing ecc · fcd05245
      Nikita Kiryanov authored
      
      
      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: default avatarNikita Kiryanov <nikita@compulab.co.il>
      fcd05245
    • Nikita Kiryanov's avatar
      mtd: nand: omap: fix sw->hw->sw ecc switch · eb237a15
      Nikita Kiryanov authored
      
      
      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: default avatarNikita Kiryanov <nikita@compulab.co.il>
      eb237a15
    • Tom Rini's avatar
      nand_util.c: Use '%zd' for length in nand_unlock debug print · 3ef1eadb
      Tom Rini authored
      
      
      length is size_t so needs to be '%zd' not '%d' to avoid warnings.
      
      Cc: Scott Wood <scottwood@freescale.com>
      Signed-off-by: default avatarTom Rini <trini@ti.com>
      3ef1eadb
    • Nikita Kiryanov's avatar
      mtd: nand: omap: fix HAM1_SW ecc using default value for ecc.size · 2528460c
      Nikita Kiryanov authored
      Commit "mtd: nand: omap: enable BCH ECC scheme using ELM for generic
      platform" (d016dc42
      
      ) 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: default avatarNikita Kiryanov <nikita@compulab.co.il>
      Acked-by: default avatarPekon Gupta <pekon@ti.com>
      2528460c
    • Stefan Roese's avatar
      mtd: nand: omap_gpmc: cosmetic: Fix indentation · 5d7a49b9
      Stefan Roese authored
      
      Signed-off-by: default avatarStefan 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: default avatarScott Wood <scottwood@freescale.com>
      5d7a49b9
    • pekon gupta's avatar
      mtd: nand: omap: fix ecc-layout for HAM1 ecc-scheme · 69cc97f8
      pekon gupta authored
      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: default avatarStefan Roese <sr@denx.de>
      Signed-off-by: default avatarPekon Gupta <pekon@ti.com>
      Tested-by: default avatarStefan Roese <sr@denx.de>
      69cc97f8
  6. 13 Dec, 2013 3 commits
  7. 11 Dec, 2013 1 commit
  8. 10 Dec, 2013 1 commit
  9. 09 Dec, 2013 5 commits
  10. 08 Dec, 2013 4 commits
  11. 06 Dec, 2013 4 commits
  12. 05 Dec, 2013 1 commit
    • Nikita Kiryanov's avatar
      arm: omap: i2c: don't zero cnt in i2c_write · 92c23c92
      Nikita Kiryanov authored
      
      
      Writing zero into I2Ci.I2C_CNT register causes random I2C failures in OMAP3
      based devices. This seems to be related to the following advisory which
      apears in multiple erratas for OMAP3 SoCs (OMAP35xx, DM37xx), as well as
      OMAP4430 TRM:
      
      Advisory:
      I2C Module Does Not Allow 0-Byte Data Requests
      Details:
      When configured as the master, the I2C module does not allow 0-byte data
      transfers. Note: Programming I2Ci.I2C_CNT[15:0]: DCOUNT = 0 will cause
      undefined behavior.
      Workaround(s):
      No workaround. Do not use 0-byte data requests.
      
      The writes in question are unnecessary from a functional point of view.
      Most of them are done after I/O has finished, and the only one that preceds
      I/O (in i2c_probe()) is also unnecessary because a stop bit is sent before
      actual data transmission takes place.
      
      Therefore, remove all writes that zero the cnt register.
      
      Cc: Heiko Schocher <hs@denx.de>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Tom Rini <trini@ti.com>
      Cc: Lubomir Popov <lpopov@mm-sol.com>
      Cc: Enric Balletbo Serra <eballetbo@gmail.com>
      Signed-off-by: default avatarNikita Kiryanov <nikita@compulab.co.il>
      Tested-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: default avatarLubomir Popov <lpopov@mm-sol.com>
      92c23c92