1. 04 9月, 2012 8 次提交
    • R
      UBI: use the whole MTD device size to get bad_peb_limit · ba4087e9
      Richard Genoud 提交于
      On NAND flash devices, UBI reserves some physical erase blocks (PEB) for
      bad block handling. Today, the number of reserved PEB can only be set as a
      percentage of the total number of PEB in each MTD partition. For example, for a
      NAND flash with 128KiB PEB, 2 MTD partition of 20MiB (mtd0) and 100MiB (mtd1)
      and 2% reserved PEB:
       - the UBI device on mtd0 will have 2 PEB reserved
       - the UBI device on mtd1 will have 16 PEB reserved
      
      The problem with this behaviour is that NAND flash manufacturers give a
      minimum number of valid block (NVB) during the endurance life of the
      device, e.g.:
      
      Parameter             Symbol    Min    Max    Unit      Notes
      --------------------------------------------------------------
      Valid block number     NVB     1004    1024   Blocks     1
      
      From this number we can deduce the maximum number of bad PEB that a device will
      contain during its endurance life: a 128MiB NAND flash (1024 PEB) will not have
      less than 20 bad blocks during the flash endurance life.
      
      But the manufacturer doesn't tell where those bad block will appear. He doesn't
      say either if they will be equally disposed on the whole device (and I'm pretty
      sure they won't). So, according to the datasheets, we should reserve the
      maximum number of bad PEB for each UBI device (worst case scenario: 20 bad
      blocks appears on the smallest MTD partition).
      
      So this patch make UBI use the whole MTD device size to calculate the maximum
      bad expected eraseblocks.
      
      The Kconfig option is in per1024 blocks, thus it can have a default value of 20
      which is *very* common for NAND devices.
      Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      ba4087e9
    • R
      mtd: mtdparts: introduce mtd_get_device_size · 62082e56
      Richard Genoud 提交于
      'mtd_get_device_size()' returns the size of the whole MTD device, that is the
      mtd_info master size. This will be used by UBI to calculate the maximum number
      of bad blocks (MBB) on a MTD device.
      
      Artem: amended the patch a bit.
      Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      62082e56
    • R
      mtd: mark mtd_is_partition argument as constant · 5dee4674
      Richard Genoud 提交于
      'struct mtd_info' is not modified by 'mtd_is_partition()' so it can be marked
      as "const".
      Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      5dee4674
    • S
      UBI: kill CONFIG_MTD_UBI_BEB_RESERVE · 1b2a5790
      Shmulik Ladkani 提交于
      CONFIG_MTD_UBI_BEB_RESERVE and MIN_RESEVED_PEBS are no longer used,
      since the amount of reserved eraseblocks for bad PEB handling is now
      derived from 'ubi->bad_peb_limit' (ubi's maximum expected bad
      eraseblocks).
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
      1b2a5790
    • S
      UBI: limit amount of reserved eraseblocks for bad PEB handling · 37f758a0
      Shmulik Ladkani 提交于
      The existing mechanism of reserving PEBs for bad PEB handling has two
      flaws:
      - It is calculated as a percentage of good PEBs instead of total PEBs.
      - There's no limit on the amount of PEBs UBI reserves for future bad
        eraseblock handling.
      
      This patch changes the mechanism to overcome these flaws.
      
      The desired level of PEBs reserved for bad PEB handling (beb_rsvd_level)
      is set to the maximum expected bad eraseblocks (bad_peb_limit) minus the
      existing number of bad eraseblocks (bad_peb_count).
      
      The actual amount of PEBs reserved for bad PEB handling is usually set
      to the desired level (but in some circumstances may be lower than the
      desired level, e.g. when attaching to a device that has too few
      available PEBs to satisfy the desired level).
      
      In the case where the device has too many bad PEBs (above the expected
      limit), then the desired level, and the actual amount of PEBs reserved
      are set to zero. No PEBs will be set aside for future bad eraseblock
      handling - even if some PEBs are made available (e.g. by shrinking a
      volume).
      If another PEB goes bad, and there are available PEBs, then the
      eraseblock will be marked bad (consuming one available PEB). But if
      there are no available PEBs, ubi will go into readonly mode.
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      37f758a0
    • S
      UBI: introduce new bad PEB limit · 8beeb3bb
      Shmulik Ladkani 提交于
      Introduce 'ubi->bad_peb_limit', which specifies an upper limit of PEBs
      UBI expects to go bad.  Currently, it is initialized to a fixed percentage
      of total PEBs in the UBI device (configurable via CONFIG_MTD_UBI_BEB_LIMIT).
      
      The 'bad_peb_limit' is intended to be used for calculating the amount of PEBs
      UBI needs to reserve for bad eraseblock handling.
      
      Artem: minor amendments.
      Signed-off-by: NShmulik Ladkani <shmulik.ladkani@gmail.com>
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@linux.intel.com>
      8beeb3bb
    • A
      183ae6cf
    • A
  2. 10 8月, 2012 1 次提交
    • A
      mtd/omap2: fix dmaengine_slave_config error handling · d680e2c1
      Arnd Bergmann 提交于
      The newly added dmaengine support in the omap2 nand driver
      potentially causes an undefined return value from the
      omap_nand_probe function when dmaengine_slave_config
      reports an error. Let's handle this by returning the
      same error back to the caller.
      
      Without this patch, building omap2plus_defconfig results in:
      
      drivers/mtd/nand/omap2.c: In function 'omap_nand_probe':
      drivers/mtd/nand/omap2.c:1154:6: warning: 'err' may be used uninitialized in this function [-Wuninitialized]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      d680e2c1
  3. 09 8月, 2012 1 次提交
    • A
      ARM: imx: gpmi-nand depends on mxs-dma · a3349377
      Arnd Bergmann 提交于
      It is not currently possible to build the gpmi-nand driver without
      also building the mxs-dma driver. Clarify this Kconfig and enable
      both in the defconfig file so we can build it again with both enabled.
      
      drivers/built-in.o: In function `gpmi_dma_filter':
      clk-fixed-factor.c:(.text+0xafc18): undefined reference to `mxs_dma_is_apbh'
      make[1]: *** [vmlinux] Error 1
      make: *** [sub-make] Error 2
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Sascha Hauer <kernel@pengutronix.de>
      a3349377
  4. 31 7月, 2012 2 次提交
  5. 25 7月, 2012 2 次提交
  6. 23 7月, 2012 1 次提交
  7. 18 7月, 2012 4 次提交
  8. 14 7月, 2012 1 次提交
  9. 06 7月, 2012 4 次提交
    • H
      mtd: nandsim: don't open code a do_div helper · 596fd462
      Herton Ronaldo Krzesinski 提交于
      We don't need to open code the divide function, just use div_u64 that
      already exists and do the same job. While this is a straightforward
      clean up, there is more to that, the real motivation for this.
      
      While building on a cross compiling environment in armel, using gcc
      4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5), I was getting the following build
      error:
      
      ERROR: "__aeabi_uldivmod" [drivers/mtd/nand/nandsim.ko] undefined!
      
      After investigating with objdump and hand built assembly version
      generated with the compiler, I narrowed __aeabi_uldivmod as being
      generated from the divide function. When nandsim.c is built with
      -fno-inline-functions-called-once, that happens when
      CONFIG_DEBUG_SECTION_MISMATCH is enabled, the do_div optimization in
      arch/arm/include/asm/div64.h doesn't work as expected with the open
      coded divide function: even if the do_div we are using doesn't have a
      constant divisor, the compiler still includes the else parts of the
      optimized do_div macro, and translates the divisions there to use
      __aeabi_uldivmod, instead of only calling __do_div_asm -> __do_div64 and
      optimizing/removing everything else out.
      
      So to reproduce, gcc 4.6 plus CONFIG_DEBUG_SECTION_MISMATCH=y and
      CONFIG_MTD_NAND_NANDSIM=m should do it, building on armel.
      
      After this change, the compiler does the intended thing even with
      -fno-inline-functions-called-once, and optimizes out as expected the
      constant handling in the optimized do_div on arm. As this also avoids a
      build issue, I'm marking for Stable, as I think is applicable for this
      case.
      Signed-off-by: NHerton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Cc: stable@vger.kernel.org
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      596fd462
    • S
      mtd: gpmi-nand: fix read page when reading to vmalloced area · 6023813a
      Sascha Hauer 提交于
      The gpmi-nand driver uses virt_addr_valid() to check whether a buffer
      is suitable for dma. If it's not, a driver allocated buffer is used
      instead. Then after a page read the driver allocated buffer must be
      copied to the user supplied buffer. This does not happen since commit
      7725cc85.
      
      This patch fixes the issue. The bug is encountered with UBI which uses a
      vmalloced buffer for the volume table.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Tested-by: snijsure@grid-net.com
      Acked-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      6023813a
    • S
      mtd: mxc_nand: use 32bit copy functions · 096bcc23
      Sascha Hauer 提交于
      The following commit changes the function used to copy from/to
      the hardware buffer to memcpy_[from|to]io. This does not work
      since the hardware cannot handle the byte accesses used by these
      functions. Instead of reverting this patch introduce 32bit
      correspondents of these functions.
      
      | commit 5775ba36ea9c760c2d7e697dac04f2f7fc95aa62
      | Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      | Date:   Tue Apr 24 10:05:22 2012 +0200
      |
      |    mtd: mxc_nand: fix several sparse warnings about incorrect address space
      |
      |     Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      |     Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      096bcc23
    • D
      mtd: cafe_nand: fix an & vs | mistake · 48f8b641
      Dan Carpenter 提交于
      The intent here was clearly to set result to true if the 0x40000000 flag
      was set.  But instead there was a | vs & typo and we always set result
      to true.
      
      Artem: check the spec at
      wiki.laptop.org/images/5/5c/88ALP01_Datasheet_July_2007.pdf
      and this fix looks correct.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      48f8b641
  10. 27 6月, 2012 2 次提交
  11. 16 6月, 2012 1 次提交
  12. 09 6月, 2012 1 次提交
  13. 07 6月, 2012 2 次提交
  14. 02 6月, 2012 4 次提交
  15. 29 5月, 2012 2 次提交
    • D
      mtd: nand: fix scan_read_raw_oob · 34a5704d
      Dmitry Maluka 提交于
      It seems there is a bug in scan_read_raw_oob() in nand_bbt.c which
      should cause wrong functioning of NAND_BBT_SCANALLPAGES option.
      
      Artem: the patch did not apply and I had to amend it a bit.
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: stable@kernel.org
      34a5704d
    • R
      mtd: docg3 fix in-middle of blocks reads · 52c2d9aa
      Robert Jarzmik 提交于
      Corner case reads do not work, and return false data and
      ECC. This case is typically seen in a ubifs usage, with a
      read of type:
       - docg3 docg3: doc_read_oob(from=14882415, mode=1,
       data=(c30eca40:12), oob=(  (null):0))
      
      This results in the following reads:
       - docg3 docg3: doc_read_data_area(buf=  (null), len=111)
       - docg3 docg3: doc_read_data_area(buf=c30eca40, len=12)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=389)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=0)
       - docg3 docg3: doc_read_data_area(buf=  (null), len=16)
      
      If we suppose that the pages content is :
       - bytes 0 .. 111   : 0x0a
       - bytes 112 .. 255 : 0x0f
      Then the returned bytes will be :
       - 111 times 0x0a (correct)
       - 0x0a 2 times and 0x0f 10 times (incorrect, should be
       0x0a,0x0f)
       - 0x0f 389 times (correct)
       - nothing
       - correct OOB
      
      The reason seams that the first 111 bytes read ends between
      the 2 docg3 planes, and that the first following read (in
      the 12 bytes sequence, read of 16 bit word) returns the byte
      of the rightmost plane duplicated in high and lower byte of
      the word.
      
      Fix this behaviour by ensuring that if the previous read
      ended up in-between the 2 planes, there will be a first 1
      byte read to get back to the beginning of leftmost plane.
      Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      52c2d9aa
  16. 21 5月, 2012 4 次提交