1. 20 6月, 2017 2 次提交
  2. 10 6月, 2017 2 次提交
    • M
      mtd: nand: denali: remove Toshiba and Hynix specific fixup code · 0615e7ad
      Masahiro Yamada 提交于
      The Denali IP can automatically detect device parameters such as
      page size, oob size, device width, etc. and this driver currently
      relies on it.  However, this hardware function is known to be
      problematic.
      
      [1] Due to a hardware bug, various misdetected cases were reported.
          That is why get_toshiba_nand_para() and get_hynix_nand_para()
          exist to fix-up the misdetected parameters.  It is not realistic
          to add a new NAND device to the *black list* every time we are
          hit by a misdetected case.  We would never be able to guarantee
          that all cases are covered.
      
      [2] Because this feature is unreliable, it is disabled on some
          platforms.
      
      The nand_scan_ident() detects device parameters in a more tested
      way.  The hardware should not set the device parameter registers in
      a different, unreliable way.  Instead, set the parameters from the
      nand_scan_ident() back to the registers.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      0615e7ad
    • M
      mtd: nand: denali: avoid hard-coding ECC step, strength, bytes · 7de117fd
      Masahiro Yamada 提交于
      This driver was originally written for the Intel MRST platform with
      several platform-specific parameters hard-coded.
      
      Currently, the ECC settings are hard-coded as follows:
      
        #define ECC_SECTOR_SIZE 512
        #define ECC_8BITS       14
        #define ECC_15BITS      26
      
      Therefore, the driver can only support two cases.
       - ecc.size = 512, ecc.strength = 8    --> ecc.bytes = 14
       - ecc.size = 512, ecc.strength = 15   --> ecc.bytes = 26
      
      However, these are actually customizable parameters, for example,
      UniPhier platform supports the following:
      
       - ecc.size = 1024, ecc.strength = 8   --> ecc.bytes = 14
       - ecc.size = 1024, ecc.strength = 16  --> ecc.bytes = 28
       - ecc.size = 1024, ecc.strength = 24  --> ecc.bytes = 42
      
      So, we need to handle the ECC parameters in a more generic manner.
      Fortunately, the Denali User's Guide explains how to calculate the
      ecc.bytes.  The formula is:
      
        ecc.bytes = 2 * CEIL(13 * ecc.strength / 16)  (for ecc.size = 512)
        ecc.bytes = 2 * CEIL(14 * ecc.strength / 16)  (for ecc.size = 1024)
      
      For DT platforms, it would be reasonable to allow DT to specify ECC
      strength by either "nand-ecc-strength" or "nand-ecc-maximize".  If
      none of them is specified, the driver will try to meet the chip's ECC
      requirement.
      
      For PCI platforms, the max ECC strength is used to keep the original
      behavior.
      
      Newer versions of this IP need ecc.size and ecc.steps explicitly
      set up via the following registers:
        CFG_DATA_BLOCK_SIZE       (0x6b0)
        CFG_LAST_DATA_BLOCK_SIZE  (0x6c0)
        CFG_NUM_DATA_BLOCKS       (0x6d0)
      
      For older IP versions, write accesses to these registers are just
      ignored.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      7de117fd
  3. 30 5月, 2017 1 次提交
  4. 25 4月, 2017 7 次提交
    • M
      mtd: nand: denali: allow to override revision number · e7beeeec
      Masahiro Yamada 提交于
      Commit 271707b1 ("mtd: nand: denali: max_banks calculation
      changed in revision 5.1") added a revision check to support the
      new max_banks encoding.  Its git-log states "The encoding of
      max_banks changed in Denali revision 5.1".
      
      There are exceptional cases, for example, the revision register on
      some UniPhier SoCs says the IP is 5.0 but the max_banks is encoded
      in the new format.
      
      This IP updates the resister specification from time to time (often
      breaking the backward compatibility), but the revision number is not
      incremented correctly.
      
      The max_banks is not only the case that needs revision checking.
      Let's allow to override an incorrect revision number.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      e7beeeec
    • M
      mtd: nand: denali: support 64bit capable DMA engine · 210a2c87
      Masahiro Yamada 提交于
      The current driver only supports the DMA engine up to 32 bit
      physical address, but there also exists 64 bit capable DMA engine
      for this IP.
      
      The data DMA setup sequence is completely different, so I added the
      64 bit DMA code as a new function denali_setup_dma64().  The 32 bit
      one has been renamed to denali_setup_dma32().
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      210a2c87
    • M
      mtd: nand: denali: support HW_ECC_FIXUP capability · 24715c74
      Masahiro Yamada 提交于
      Some old versions of the Denali IP (perhaps used only for Intel?)
      detects ECC errors and provides correct data via a register, but
      does not touch the transferred data.  So, the software must fixup
      the data in the buffer according to the provided ECC correction
      information.
      
      Newer versions perform ECC correction before transferring the data.
      No more software intervention is needed.  The ECC_ERROR_ADDRESS and
      ECC_CORRECTION_INFO registers were deprecated.  Instead, the number
      of corrected bit-flips are reported via the ECC_COR_INFO register.
      When an uncorrectable ECC error happens, a status flag is set to the
      INTR_STATUS and ECC_COR_INFO registers.
      
      As is often the case with this IP, the register view of INTR_STATUS
      had broken compatibility.
      
      For older versions (SW ECC fixup):
        bit 0:  ECC_TRANSACTION_DONE
        bit 1:  ECC_ERR
      
      For newer versions (HW ECC fixup):
        bit 0:  ECC_UNCOR_ERR
        bit 1:  Reserved
      
      Due to this difference, the irq_mask must be fixed too.
      
      The existing handle_ecc() has been renamed to denali_sw_ecc_fixup()
      for clarification.
      
      What is unfortunate with this feature is we can not know the total
      number of corrected/uncorrected errors in a page.  The register
      ECC_COR_INFO reports the maximum of per-sector bitflips.  This is
      useful for ->read_page return value, but ecc_stats.{corrected,failed}
      increments may not be precise.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      24715c74
    • M
      mtd: nand: denali: fix erased page checking · d29109be
      Masahiro Yamada 提交于
      This part is wrong in multiple ways:
      
      [1] is_erased() is called against "buf" twice, so the OOB area is
      not checked at all.  The second call should check chip->oob_poi.
      
      [2] This code block is nested by double "if (check_erase_page)".
      The inner one is redundant.
      
      [3] The ECC_ERROR_ADDRESS register reports which sector(s) had
      uncorrectable ECC errors.  It is pointless to check the whole page
      if only one sector contains errors.
      
      [4] Unfortunately, the Denali ECC correction engine has already
      manipulated the data buffer before it decides the bitflips are
      uncorrectable.  That is, not all of the data are 0xFF after an
      erased page is processed by the ECC engine.  The current is_erased()
      helper could report false-positive ECC errors.  Actually, a certain
      mount of bitflips are allowed in an erased page.  The core framework
      provides nand_check_erased_ecc_chunk() that takes the threshold into
      account.  Let's use this.
      
      This commit reworks the code to solve those problems.
      
      Please note the erased page checking is implemented as a separate
      helper function instead of embedding it in the loop in handle_ecc().
      The reason is that OOB data are needed for the erased page checking,
      but the controller can not start a new transaction until all ECC
      error information is read out from the registers.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      d29109be
    • M
      mtd: nand: denali: fix bitflips calculation in handle_ecc() · 20d48595
      Masahiro Yamada 提交于
      This function is wrong in multiple ways:
      
      [1] Counting corrected bytes instead of corrected bits.
      
      The following code is counting the number of corrected _bytes_.
      
          /* correct the ECC error */
          buf[offset] ^= err_cor_value;
          mtd->ecc_stats.corrected++;
          bitflips++;
      
      What the core framework expects is the number of corrected _bits_.
      They can be different if multiple bitflips occur within one byte.
      
      [2] total number of errors instead of max of per-sector errors
      
      The core framework expects that corrected errors are counted per
      sector, then the max value should be taken.  The current code simply
      iterates over the whole page, i.e. counts the total number of
      correction in the page.  This means "too many bitflips" is triggered
      earlier than it should be, i.e. the NAND device is worn out sooner.
      
      Besides those bugs, this function is unreadable due to the deep
      nesting.  Notice the whole code in this function is wrapped in
      if (irq_status & INTR__ECC_ERR), so this conditional can be moved
      out of the function.  Also, use shorter names for local variables.
      
      Re-work the function to fix all the issues.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      20d48595
    • M
      mtd: nand: denali: remove meaningless pipeline read-ahead operation · 8927ad39
      Masahiro Yamada 提交于
      The pipeline read-ahead function of the Denali IP enables continuous
      reading from the device; while data is being read out by a CPU, the
      controller maintains additional commands for streaming data from the
      device.  This will reduce the latency of the second page or later.
      
      This feature is obviously no help for per-page accessors of Linux
      NAND driver interface.
      
      In the current implementation, the pipeline command is issued to
      load a single page, then data are read out immediately.  The use of
      the pipeline operation is not adding any advantage, but just adding
      complexity to the code.  Remove.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      8927ad39
    • M
      mtd: nand: denali: allow to override mtd->name from label DT property · 8aabdf37
      Masahiro Yamada 提交于
      Commit 28309572 ("mtd: name the mtd device with an optional
      label property") allow us to identify a chip in a user-friendly way.
      
      If nand_set_flash_node() picks up the "label" from DT, let's respect
      it.  Otherwise, let it fallback to the current name "denali-nand".
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      8aabdf37
  5. 28 3月, 2017 4 次提交
  6. 27 3月, 2017 3 次提交
  7. 24 3月, 2017 3 次提交
  8. 19 11月, 2016 11 次提交
  9. 06 5月, 2016 1 次提交
  10. 19 12月, 2015 2 次提交
  11. 12 12月, 2015 1 次提交
  12. 14 10月, 2015 2 次提交
    • B
      mtd: nand: pass page number to ecc->write_xxx() methods · 45aaeff9
      Boris BREZILLON 提交于
      The ->read_xxx() methods are all passed the page number the NAND controller
      is supposed to read, but ->write_xxx() do not have such a parameter.
      
      This is a problem if we want to properly implement data
      scrambling/randomization in order to mitigate MLC sensibility to repeated
      pattern: to prevent bitflips in adjacent pages in the same block we need
      to avoid repeating the same pattern at the same offset in those pages,
      hence the randomizer/scrambler engine need to be passed the page value
      in order to adapt its seed accordingly.
      
      Moreover, adding the page parameter to the ->write_xxx() methods add some
      consistency to the current API.
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      CC: Josh Wu <josh.wu@atmel.com>
      CC: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      CC: Maxime Ripard <maxime.ripard@free-electrons.com>
      CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      CC: Huang Shijie <shijie.huang@arm.com>
      CC: Stefan Agner <stefan@agner.ch>
      CC: devel@driverdev.osuosl.org
      CC: linux-arm-kernel@lists.infradead.org
      CC: linux-kernel@vger.kernel.org
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      45aaeff9
    • F
      mtd: nand: denali: drop owner assignment · fbe1a8bf
      Frans Klaver 提交于
      Owner is automatically set by mtdcore. Make use of that.
      Signed-off-by: NFrans Klaver <fransklaver@gmail.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      fbe1a8bf
  13. 30 9月, 2015 1 次提交