1. 25 Apr, 2017 13 commits
    • Masahiro Yamada's avatar
      mtd: nand: denali_dt: use pdev instead of ofdev for platform_device · 3f5c3581
      Masahiro Yamada authored
      "pdev" is much more often used to point a platform_device, so this
      will help the driver code look consistent across the kernel.
      
      While we are here, fix "line over 80 characters" coding style
      violations.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      3f5c3581
    • Masahiro Yamada's avatar
      mtd: nand: denali_dt: remove dma-mask DT property · 60d920d3
      Masahiro Yamada authored
      The driver sets appropriate DMA mask.  Delete the "dma-mask" DT
      property.  See [1] for negative comments for this binding.
      
      [1] https://lkml.org/lkml/2016/2/8/57Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      60d920d3
    • Masahiro Yamada's avatar
      mtd: nand: denali: support 64bit capable DMA engine · 210a2c87
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      210a2c87
    • Masahiro Yamada's avatar
      mtd: nand: denali_dt: enable HW_ECC_FIXUP for Altera SOCFPGA variant · a56609c4
      Masahiro Yamada authored
      There are various customizable parameters, so several variants for
      this IP.  A generic compatible like "denali,denali-nand-dt" is
      useless.  Moreover, there are multiple things wrong with this string.
      (Refer to Rob's comment [1])
      
      The "denali,denali-nand-dt" was added by Altera for the SOCFPGA port.
      Replace it with a more specific string "altr,socfpga-denali-nand".
      There are no users (in upstream) of the old compatible string.
      
      The Denali IP on SOCFPGA incorporates the hardware ECC fixup engine.
      So, this capability should be associated with the compatible.
      
      [1] https://lkml.org/lkml/2016/12/1/450Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      a56609c4
    • Masahiro Yamada's avatar
      mtd: nand: denali: support HW_ECC_FIXUP capability · 24715c74
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      24715c74
    • Masahiro Yamada's avatar
      mtd: nand: denali: fix erased page checking · d29109be
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      d29109be
    • Masahiro Yamada's avatar
      mtd: nand: denali: fix bitflips calculation in handle_ecc() · 20d48595
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      20d48595
    • Masahiro Yamada's avatar
      mtd: nand: denali: remove meaningless pipeline read-ahead operation · 8927ad39
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      8927ad39
    • Masahiro Yamada's avatar
      mtd: nand: denali: allow to override mtd->name from label DT property · 8aabdf37
      Masahiro Yamada authored
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Suggested-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      8aabdf37
    • Masahiro Yamada's avatar
      mtd: nand: relax ecc.read_page() return value for uncorrectable ECC · 07604686
      Masahiro Yamada authored
      The comment for ecc.read_page() requires that it should return
      "0 if bitflips uncorrectable".
      
      Actually, drivers could return positive values when uncorrectable
      bitflips occur.  For example, nand_read_page_swecc() is the case.
      If ecc.correct() returns -EBADMSG for the first ECC sector, and
      a positive value for the second one, nand_read_page_swecc() returns
      a positive max_bitflips and increments ecc_stats.failed for the same
      page.
      
      The requirement can be relaxed by tweaking nand_do_read_ops().
      Move the max_bitflips calculation below the retry.
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Suggested-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      07604686
    • Boris Brezillon's avatar
      mtd: nand: Remove unused chip->write_page() hook · f107d7a4
      Boris Brezillon authored
      The last/only user of the chip->write_page() hook (the Atmel NAND
      controller driver) has been reworked and is no longer specifying a custom
      ->write_page() implementation.
      Drop this hook before someone else start abusing it.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f107d7a4
    • Boris Brezillon's avatar
      mtd: nand: atmel: Document the new DT bindings · 82d0bf34
      Boris Brezillon authored
      The old NAND bindings were not exactly describing the hardware topology
      and were preventing definitions of several NAND chips under the same
      NAND controller.
      
      New bindings address these limitations and should be preferred over the
      old ones for new SoCs/boards.
      Old bindings are still supported for backward compatibility but are
      marked deprecated in the doc.
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Reviewed-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      82d0bf34
    • Boris Brezillon's avatar
      mtd: nand: Cleanup/rework the atmel_nand driver · f88fc122
      Boris Brezillon authored
      This is a complete rewrite of the driver whose main purpose is to
      support the new DT representation where the NAND controller node is now
      really visible in the DT and appears under the EBI bus. With this new
      representation, we can add other devices under the EBI bus without
      risking pinmuxing conflicts (the NAND controller is under the EBI
      bus logic and as such, share some of its pins with other devices
      connected on this bus).
      
      Even though the goal of this rework was not necessarily to add new
      features, the new driver has been designed with this in mind. With a
      clearer separation between the different blocks and different IP
      revisions, adding new functionalities should be easier (we already
      have plans to support SMC timing configuration so that we no longer
      have to rely on the configuration done by the bootloader/bootstrap).
      
      Also note that we no longer have a custom ->cmdfunc() implementation,
      which means we can now benefit from new features added in the core
      implementation for free (support for new NAND operations for example).
      
      The last thing that we gain with this rework is support for multi-chips
      and multi-dies chips, thanks to the clean NAND controller <-> NAND
      devices representation.
      
      During this transition we also dropped support for AVR32 SoCs which
      should soon disappear from mainline (removal of the AVR32 arch is
      planned for 4.12).
      
      This new driver has been tested on several platforms (at91sam9261,
      at91sam9g45, at91sam9x5, sama5d3 and sama5d4) to make sure it did not
      introduce regressions, and it's worth mentioning that old bindings are
      still supported (which partly explain the positive diffstat).
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      f88fc122
  2. 29 Mar, 2017 2 commits
  3. 28 Mar, 2017 4 commits
  4. 27 Mar, 2017 3 commits
  5. 24 Mar, 2017 11 commits
  6. 23 Mar, 2017 7 commits