21 May, 2019

1 commit


18 Apr, 2019

1 commit


18 Jul, 2018

1 commit


15 Mar, 2018

1 commit


16 Feb, 2018

2 commits


12 Jan, 2018

1 commit

  • Add marvell_nand driver which aims at replacing the existing pxa3xx_nand
    driver.

    The new driver intends to be easier to understand and follows the brand
    new NAND framework rules by implementing hooks for every pattern the
    controller might support and referencing them inside a parser object
    that will be given to the core at each ->exec_op() call.

    Raw accessors are implemented, useful to test/debug memory/filesystem
    corruptions. Userspace binaries contained in the mtd-utils package may
    now be used and their output trusted.

    Most of the DT nodes using the old driver kept non-optimal timings from
    the bootloader (even if there was some mechanisms to derive them if the
    chip was ONFI compliant). The new default is to implement
    ->setup_data_interface() and follow the core's decision regarding the
    chip.

    Thanks to the improved timings, implementation of ONFI mode 5 support
    (with EDO managed by adding a delay on data sampling), merging the
    commands together and optimizing writes in the command registers, the
    new driver may achieve faster throughputs in both directions.
    Measurements show an improvement of about +23% read throughput and +24%
    write throughput. These measurements have been done with an
    Armada-385-DB-AP (4kiB NAND pages forced in 4-bit strength BCH ECC
    correction) using the userspace tool 'flash_speed' from the MTD test
    suite.

    Besides these important topics, the new driver addresses several
    unsolved known issues in the old driver which:
    - did not work with ECC soft neither with ECC none ;
    - relied on naked read/write (which is unchanged) while the NFCv1
    embedded in the pxa3xx platforms do not implement it, so several
    NAND commands did not actually ever work without any notice (like
    reading the ONFI PARAM_PAGE or SET/GET_FEATURES) ;
    - wrote the OOB data correctly, but was not able to read it correctly
    past the first OOB data chunk ;
    - did not retrieve ECC bytes ;
    - used device tree bindings that did not allow more than one NAND chip,
    and did not allow to choose the correct chip select if not
    incrementing from 0. Plus, the Ready/Busy line used had to be 0.

    Old device tree bindings are still supported but deprecated. A more
    hierarchical view has to be used to keep the controller and the NAND
    chip structures clearly separated both inside the device tree and also
    in the driver code.

    Signed-off-by: Miquel Raynal
    Tested-by: Sean Nyekjaer
    Tested-by: Willy Tarreau
    Signed-off-by: Boris Brezillon

    Miquel Raynal
     

01 Dec, 2017

1 commit

  • The GPMI nand Kconfig help texts mentions that the GPMI nand driver
    might conflict with SD cards. The only conflict there might really
    be is that both controllers use the same pins, but this is resolved
    by the pincontroller setup in the device tree. In any way the GPMI
    driver can safely be enabled, the text is just wrong. Remove it.

    Signed-off-by: Sascha Hauer
    Reviewed-by: Fabio Estevam
    Acked-by: Han Xu
    Signed-off-by: Boris Brezillon

    Sascha Hauer
     

07 Oct, 2017

1 commit


23 Aug, 2017

1 commit


01 Jun, 2017

1 commit


15 May, 2017

2 commits


25 Apr, 2017

1 commit

  • 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: Boris Brezillon
    Acked-by: Nicolas Ferre

    Boris Brezillon
     

24 Mar, 2017

1 commit

  • All of these macros are not used at all.
    CONFIG_MTD_NAND_DENALI_SCRATCH_REG_ADDR is not used for anything but
    defining SCRATCH_REG_ADDR. The config option should go away as well.

    I am removing some register macros. They are not used, and do not
    exist in recent IP versions.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Boris Brezillon

    Masahiro Yamada
     

16 Mar, 2017

1 commit

  • As NAND support for Freescale/NXP IFC controller is available on
    LS1021A, the dependency for LS1021A is added.

    LS1021A is an earlier product and is not compatible with later
    LayerScape architecture. So ARCH_LAYERSCAPE can't cover LS1021A.

    Signed-off-by: Alison Wang
    Signed-off-by: Boris Brezillon

    Alison Wang
     

09 Mar, 2017

1 commit

  • MTD_NAND_IDS is selected by MTD_NAND, which makes it useless. Remove
    the Kconfig option and link nand_ids.o into the nand.o object file.
    Doing that also prevents creating an extra nand_ids.ko module when
    MTD_NAND is activated as a module.

    Since nand_ids.c is no longer compiled as a standalone module and the
    nand_manuf_ids/nand_flash_ids symbols are only used in nand_base.c, we
    can get rid of the MODULE_XXX() and EXPORT_SYMBOL() definitions.

    Signed-off-by: Boris Brezillon

    Boris Brezillon
     

30 Jan, 2017

2 commits

  • The oxnas NAND driver is only needed for a specific platform, do
    not propose it on other platforms unless build-testing.

    Signed-off-by: Jean Delvare
    Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support")
    Cc: Rob Herring
    Cc: Neil Armstrong
    Cc: Boris Brezillon
    Cc: Richard Weinberger
    Cc: David Woodhouse
    Cc: Brian Norris
    Cc: Marek Vasut
    Cc: Cyrille Pitchen
    Acked-by: Marek Vasut
    Acked-by: Neil Armstrong
    Signed-off-by: Boris Brezillon

    Jean Delvare
     
  • The FSMC driver has an execution path and a header file in
    that serves to support passing in platform
    data through board files, albeit no upstream users of this
    mechanism exist.

    The header file also contains function headers for functions that
    do not exist in the kernel.

    Delete this and move the platform data struct, parsing and
    handling into the driver, assume we are using OF and make the
    driver depend on OF, remove the ifdefs making that optional.

    Cc: Viresh Kumar
    Cc: Stefan Roese
    Cc: Vipin Kumar
    Signed-off-by: Linus Walleij
    Reviewed-by: Stefan Roese
    Acked-by: Viresh Kumar
    Signed-off-by: Boris Brezillon

    Linus Walleij
     

02 Jan, 2017

2 commits

  • Fix build errors on arch/um, which does not support HAS_IOMEM,
    while the oxnas_nand.c driver uses interfaces that are
    supplied by HAS_IOMEM.

    (loadable module build:)
    ERROR: "devm_ioremap_resource" [drivers/mtd/nand/oxnas_nand.ko] undefined!
    or (built-in build:)
    drivers/built-in.o: In function `oxnas_nand_probe':
    drivers/mtd/nand/oxnas_nand.c:102: undefined reference to `devm_ioremap_resource'

    Fixes: 668592492409 ("mtd: nand: Add OX820 NAND Support")
    Signed-off-by: Randy Dunlap
    Reported-by: kbuild test robot
    Acked-by: Neil Armstrong
    Signed-off-by: Boris Brezillon

    Randy Dunlap
     
  • The xway_nand driver accesses the ltq_ebu_membase symbol which is not
    exported. This also should not get exported and we should handle the
    EBU interface in a better way later. This quick fix just deactivated
    support for building as module.

    Fixes: 99f2b107924c ("mtd: lantiq: Add NAND support on Lantiq XWAY SoC.")
    Cc:
    Signed-off-by: Hauke Mehrtens
    Signed-off-by: Boris Brezillon

    Hauke Mehrtens
     

07 Nov, 2016

2 commits


22 Oct, 2016

1 commit

  • Add NAND driver to support the Oxford Semiconductor OX820 NAND Controller.
    This is a simple memory mapped NAND controller with single chip select and
    software ECC.

    Acked-by: Rob Herring
    Signed-off-by: Neil Armstrong
    Signed-off-by: Boris Brezillon

    Neil Armstrong
     

23 Sep, 2016

3 commits


16 Jul, 2016

1 commit

  • Pull NAND changes from Boris Brezillon:
    """
    This pull request contains only one notable change:
    * Addition of the MTK NAND controller driver

    And a bunch of specific NAND driver improvements/fixes. Here are the
    changes that are worth mentioning:
    * A few fixes/improvements for the xway NAND controller driver
    * A few fixes for the sunxi NAND controller driver
    * Support for DMA in the sunxi NAND driver
    * Support for the sunxi NAND controller IP embedded in A23/A33 SoCs
    * Addition for bitflips detection in erased pages to the brcmnand driver
    * Support for new brcmnand IPs
    * Update of the OMAP-GPMC binding to support DMA channel description
    """

    Brian Norris
     

14 Jul, 2016

1 commit

  • This patch enables IFC NAND support on ARM layerscape platform.
    It fixes the dependency to enable NAND. The include files are being modified
    to ensure complilation for both PowerPC and ARM architectures.

    Signed-off-by: Raghav Dogra
    Acked-by: Scott Wood
    Signed-off-by: Brian Norris

    Raghav Dogra
     

11 Jul, 2016

2 commits


11 Mar, 2016

1 commit

  • The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx,
    MDM9x15 series.

    It exists as a sub block inside the IPs EBI2 (External Bus Interface 2)
    and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a
    broader interface for external slow peripheral devices such as LCD and
    NAND/NOR flash memory or SRAM like interfaces.

    We add support for the NAND controller found within EBI2. For the SoCs
    of our interest, we only use the NAND controller within EBI2. Therefore,
    it's safe for us to assume that the NAND controller is a standalone block
    within the SoC.

    The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND
    flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and
    16 bit correction/step) and RS ECC(4 bit correction/step) that covers main
    and spare data. The controller contains an internal 512 byte page buffer
    to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA
    for register read/write and data transfers. The controller performs page
    reads and writes at a codeword/step level of 512 bytes. It can support up
    to 2 external chips of different configurations.

    The driver prepares register read and write configuration descriptors for
    each codeword, followed by data descriptors to read or write data from the
    controller's internal buffer. It uses a single ADM DMA channel that we get
    via dmaengine API. The controller requires 2 ADM CRCIs for command and
    data flow control. These are passed via DT.

    The ecc layout used by the controller is syndrome like, but we can't use
    the standard syndrome ecc ops because of several reasons. First, the amount
    of data bytes covered by ecc isn't same in each step. Second, writing to
    free oob space requires us writing to the entire step in which the oob
    lies. This forces us to create our own ecc ops.

    One more difference is how the controller accesses the bad block marker.
    The controller ignores reading the marker when ECC is enabled. ECC needs
    to be explicity disabled to read or write to the bad block marker. The
    nand_bbt helpers library hence can't access BBMs for the controller.
    For now, we skip the creation of BBT and populate chip->block_bad and
    chip->block_markbad helpers instead.

    Reviewed-by: Andy Gross
    Signed-off-by: Stephen Boyd
    Signed-off-by: Archit Taneja
    Reviewed-by: Boris Brezillon
    Signed-off-by: Brian Norris

    Archit Taneja
     

02 Feb, 2016

1 commit


27 Jan, 2016

1 commit


08 Jan, 2016

1 commit

  • Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
    well as the hardware BCH controller. DMA is not currently implemented.

    While older 47xx SoCs also have a BCH controller, they are incompatible
    with the one in the 4780 due to differing register/bit positions, which
    would make implementing a common driver for them quite messy.

    Signed-off-by: Alex Smith
    Cc: Zubair Lutfullah Kakakhel
    Cc: David Woodhouse
    Cc: linux-mtd@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Harvey Hunt
    Reviewed-by: Boris Brezillon
    [Brian: fixed a few small mistakes]
    Signed-off-by: Brian Norris

    Alex Smith
     

19 Dec, 2015

1 commit


10 Dec, 2015

1 commit


13 Oct, 2015

1 commit


30 Sep, 2015

2 commits

  • This adds hardware ECC support using the BCH encoder in the NFC IP.
    The ECC encoder supports up to 32-bit correction by using 60 error
    correction bytes. There is no sub-page ECC step, ECC is calculated
    always across the whole page (up to 2k pages).

    Limitations:
    - HW ECC: Only 2K page with 64+ OOB.
    - HW ECC: Only 24 and 32-bit error correction implemented.

    Raw writes have been tested using the generic nand_write_page_raw
    implementation. However, raw reads are currently not possible
    because the controller need to know whether we are going to use
    the ECC mode already at NAND_CMD_READ0 command time. At this point
    we do not have the information whether it is a raw read or a
    regular read at driver level...

    Signed-off-by: Bill Pringlemeir
    Signed-off-by: Stefan Agner
    Signed-off-by: Brian Norris

    Stefan Agner
     
  • This driver supports Freescale NFC (NAND flash controller) found on
    Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has
    been tested using 8-bit and 16-bit NAND interface on the ARM based
    Vybrid SoC VF500 and VF610 platform.
    parameter page reading.

    Limitations:
    - Untested on MPC5125 and M54418.
    - DMA and pipelining not used.
    - 2K pages or less.
    - No chip select, one NAND chip per controller.
    - No hardware ECC.

    Some paths have been hand-optimized and evaluated by measurements
    made using mtd_speedtest.ko on a 100MB MTD partition.

    Colibri VF50
    eb write % eb read % page write % page read %
    rel/opt 5175 11537 4560 11039
    opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10
    none 5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58

    Colibri VF61
    eb write % eb read % page write % page read %
    rel/opt 5766 13096 5459 12846
    opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34
    none 5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86

    rel = using readl_relaxed/writel_relaxed in optimized paths
    opt = hand-optimized by combining multiple accesses into one read/write

    The measurements have not been statistically verfied, hence use them
    with care. The author came to the conclusion that using the relaxed
    variants of readl/writel are not worth the additional code.

    Signed-off-by: Bill Pringlemeir
    Tested-by: Albert ARIBAUD
    Signed-off-by: Stefan Agner
    Reviewed-by: Alexey Klimov
    Signed-off-by: Brian Norris

    Stefan Agner