Remove leftover from nor->cmd_buf.
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>

The description was interleaved.
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>

The spi-mem layer provides a spi_mem_supports_op() function to check
whether a specific operation is supported by the controller or not.
This is much more accurate than the hwcaps selection logic based on
SPI_{RX,TX}_ flags.

Rework the hwcaps selection logic to use spi_mem_supports_op() when
nor->spimem != NULL.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>

The m25p80 driver is actually a generic wrapper around the spi-mem
layer. Not only the driver name is misleading, but we'd expect such a
common logic to be directly available in the core. Another reason for
moving this code is that SPI NOR controller drivers should
progressively be replaced by SPI controller drivers implementing the
spi_mem_ops interface, and when the conversion is done, we should have
a single spi-nor driver directly interfacing with the spi-mem layer.

While moving the code we also fix a longstanding issue when
non-DMA-able buffers are passed by the MTD layer.
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>

spi-mem layer expects all buffers passed to it to be DMA'able. But
spi-nor layer mostly allocates buffers on stack for reading/writing to
registers and therefore are not DMA'able. Introduce bounce buffer to be
used to read/write to registers. This ensures that buffer passed to
spi-mem layer during register read/writes is DMA'able. With this change
nor->cmd-buf is no longer used, so drop it.
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>

Add initial support for Paragon Technology
PN26G01Axxxxx and PN26G02Axxxxx SPI NAND

Datasheets available at
http://www.xtxtech.com/upfile/2016082517274590.pdf
http://www.xtxtech.com/upfile/2016082517282329.pdfSigned-off-by: NJeff Kletsky <git-commits@allycomm.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Added a flag to indicate a panic_write so that low level drivers can
use it to take required action where applicable, to ensure oops data
gets written to assigned mtd device.
Signed-off-by: NKamal Dasu <kdasu.kdev@gmail.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes two-byte device IDs.

http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/Signed-off-by: NJeff Kletsky <git-commits@allycomm.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The GigaDevice GD5F1GQ4UFxxG SPI NAND utilizes three-byte addresses
for its page-read ops.

http://www.gigadevice.com/datasheet/gd5f1gq4xfxxg/Signed-off-by: NJeff Kletsky <git-commits@allycomm.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The NAND core has a NAND operation tracing function, but it can only
be used by drivers using the generic option parser from the NAND core.
Export the tracing function as a static inline function in rawnand.h
so that drivers implementing exec_op directly do not have to write their
own operation tracing.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Used in several S5PV210-based Galaxy S devices, among them SGH-T959V,
SGH-T959P, SGH-T839, and SPH-D700.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Cypress' HyperBus is Low Signal Count, High Performance Double Data Rate
Bus interface between a host system master and one or more slave
interfaces. HyperBus is used to connect microprocessor, microcontroller,
or ASIC devices with random access NOR flash memory (called HyperFlash)
or self refresh DRAM (called HyperRAM).

Its a 8-bit data bus (DQ[7:0]) with  Read-Write Data Strobe (RWDS)
signal and either Single-ended clock(3.0V parts) or Differential clock
(1.8V parts). It uses ChipSelect lines to select b/w multiple slaves.
At bus level, it follows a separate protocol described in HyperBus
specification[1].

HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar
to that of existing parallel NORs. Since HyperBus is x8 DDR bus,
its equivalent to x16 parallel NOR flash with respect to bits per clock
cycle. But HyperBus operates at >166MHz frequencies.
HyperRAM provides direct random read/write access to flash memory
array.

But, HyperBus memory controllers seem to abstract implementation details
and expose a simple MMIO interface to access connected flash.

Add support for registering HyperFlash devices with MTD framework. MTD
maps framework along with CFI chip support framework are used to support
communicating with flash.

Framework is modelled along the lines of spi-nor framework. HyperBus
memory controller (HBMC) drivers calls hyperbus_register_device() to
register a single HyperFlash device. HyperFlash core parses MMIO access
information from DT, sets up the map_info struct, probes CFI flash and
registers it with MTD framework.

Some HBMC masters need calibration/training sequence[3] to be carried
out, in order for DLL inside the controller to lock, by reading a known
string/pattern. This is done by repeatedly reading CFI Query
Identification String. Calibration needs to be done before trying to detect
flash as part of CFI flash probe.

HyperRAM is not supported at the moment.

HyperBus specification can be found at[1]
HyperFlash datasheet can be found at[2]

[1] https://www.cypress.com/file/213356/download
[2] https://www.cypress.com/file/213346/download
[3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf
    Table 12-5741. HyperFlash Access Sequence
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command
Set (0x0002) for flash operations, therefore
drivers/mtd/chips/cfi_cmdset_0002.c can be used as is. But these devices
do not support DQ polling method of determining chip ready/good status.
These flashes provide Status Register whose bits can be polled to know
status of flash operation.

Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu
Extended Query version 1.5. Bit 0 of "Software Features supported" field
of CFI Primary Vendor-Specific Extended Query table indicates
presence/absence of status register and Bit 1 indicates whether or not
DQ polling is supported. Using these bits, its possible to determine
whether flash supports DQ polling or need to use Status Register.

Add support for polling Status Register to know device ready/status of
erase/write operations when DQ polling is not supported.
Print error messages on erase/program failure by looking at related
Status Register bits.

[1] https://www.cypress.com/file/213346/downloadSigned-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NTokunori Ikegami <ikegami.t@gmail.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

SPI memory devices from different manufacturers have widely
different configurations for Status, Control and Configuration
registers. JEDEC 216C defines a new map for these common register
bits and their functions, and describes how the individual bits may
be accessed for a specific device. For the JEDEC 216B compliant
flashes, we can partially deduce Status and Configuration registers
functions by inspecting the 16th DWORD of BFPT. Older flashes that
don't declare the SFDP tables (SPANSION FL512SAIFG1 311QQ063 A ©11
SPANSION) let the software decide how to interact with these registers.

The commit dcb4b22e ("spi-nor: s25fl512s supports region locking")
uncovered a probe error for s25fl512s, when the Quad Enable bit CR[1]
was set to one in the bootloader. When this bit is one, only the Write
Status (01h) command with two data byts may be used, the 01h command with
one data byte is not recognized and hence the error when trying to clear
the block protection bits.

Fix the above by using the Write Status (01h) command with two data bytes
when the Quad Enable bit is one.

Backward compatibility should be fine. The newly introduced
spi_nor_spansion_clear_sr_bp() is tightly coupled with the
spansion_quad_enable() function. Both assume that the Write Register
with 16 bits, together with the Read Configuration Register (35h)
instructions are supported.

Fixes: dcb4b22e ("spi-nor: s25fl512s supports region locking")
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Tested-by: NJonas Bonn <jonas@norrbonn.se>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NVignesh Raghavendra <vigneshr@ti.com>
Tested-by: NVignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NEnrico Weigelt <info@metux.net>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 24 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAlexios Zavras <alexios.zavras@intel.com>
Reviewed-by: NSteve Winslow <swinslow@gmail.com>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Reviewed-by: NRichard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190528170026.162703968@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version this program is distributed in the
  hope that it will be useful but without any warranty without even
  the implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details you
  should have received a copy of the gnu general public license along
  with this program if not write to the free software foundation inc
  59 temple place suite 330 boston ma 02111 1307 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Reviewed-by: NRichard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version this program is distributed in the
  hope that it will be useful but without any warranty without even
  the implied warranty of merchantability or fitness for a particular
  purpose see the gnu general public license for more details you
  should have received a copy of the gnu general public license along
  with this program if not write to the free software foundation inc
  51 franklin st fifth floor boston ma 02110 1301 usa

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 50 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Reviewed-by: NRichard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190523091649.499889647@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

To be able to check and set bad block markers in the first and
second page of a block independently of each other, we create
separate flags for both cases.

Previously NAND_BBM_SECONDPAGE meant, that both, the first and the
second page were used. With this patch NAND_BBM_FIRSTPAGE stands for
using the first page and NAND_BBM_SECONDPAGE for using the second
page.

This patch is only for preparation of subsequent changes and does
not implement the logic to actually handle both flags separately.
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: NBoris Brezillon <bbrezillon@kernel.org>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Now that we have moved the information to the chip level, let's
remove all the unused flags and fields.
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to the chip struct,
as we did it for rawnand.
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

The information about where the manufacturer puts the bad block
markers inside the bad block and in the OOB data is stored in
different places. Let's move this information to nand_chip.options
and nand_chip.badblockpos.

As this chip-specific information is not directly related to the
bad block table (BBT), we also rename the flags to NAND_BBM_*.
Signed-off-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Currently, drivers are able to constify a nand_op_parser array,
but not nand_op_parser_pattern and nand_op_parser_pattern_elem
since they are instantiated by using the NAND_OP_PARSER(_PATTERN).

Add 'const' to them in order to move more driver data from .data to
.rodata section.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NBoris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Sphinx doesn't handle expressions in identifier references.

This fixes the following warnings:

./include/linux/mtd/rawnand.h:1184: WARNING: Inline strong start-string without end-string.
./include/linux/mtd/rawnand.h:1186: WARNING: Inline strong start-string without end-string.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

There is no point in having two distinct entries, merge them and
rename the symbol for more clarity: MTD_NAND_ECC_SW_BCH
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

nand_device embeds a nand_ecc_req object which contains the minimum
strength and step-size required by the NAND device.

Drop the chip->ecc_{strength,step}_ds fields and use
chip->base.eccreq.{strength,step_size} instead.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

The same information is provided by nanddev_ntargets().
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

The target size can now be returned by nanddev_get_targetsize(). Get
rid of the chip->chipsize field and use this helper instead.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>

Now that we inherit from nand_device, we can use
nand_device->memorg.bits_per_cell instead of having our own field at
the nand_chip level.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

nanddev_mtd_max_bad_blocks() is implemented by the generic NAND layer
and is already doing what we need. Reuse this function instead of
having our own implementation.

While at it, get rid of the ->max_bb_per_die and ->blocks_per_die
fields which are now unused.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

Looking at the field names it's hard to tell what ->data_buf, ->pagebuf
and ->pagebuf_bitflips are for. Clarify that by moving those fields
in a sub-struct named pagecache.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

We plan to move cache related fields to a pagecache struct in nand_chip
but some drivers access ->pagebuf directly to invalidate the cache
before they start using ->data_buf.

Let's provide an helper that returns a pointer to ->data_buf after
invalidating the cache.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

The generic NAND layer provides abstraction of NAND devices no matter
the bus that is used to communicate with the chip. Basing the raw NAND
core on this generic layer should avoid duplication of common
operations, like iterating over all pages/blocks for MTD IO/erase
operations.

In order to re-use this layer, we must first inherit from nand_device
and then initialize the nand_device struct appropriately. This patch
is taking care of the former.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

Use the nand_to_mtd() helper to access chip->mtd as done everywhere
else.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

Will be used by the raw NAND framework.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

Some drivers in the raw NAND framework seems to need this helper, so
let's just add it instead of open-coding the logic.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

NAND datasheets usually give the maximum number of bad blocks per LUN
and this number can be used to help upper layers decide how much blocks
they should reserve for bad block handling.

Add a max_bad_eraseblocks_per_lun to the nand_memory_organization
struct and update the NAND_MEMORG() macro (and its users) accordingly.

We also provide a default mtd->_max_bad_blocks() implementation.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: NFrieder Schrempf <frieder.schrempf@kontron.de>

Make use of the spi-mem direct mapping API to let advanced controllers
optimize read/write operations when they support direct mapping.
Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Tested-by: NStefan Roese <sr@denx.de>

Change SNOR_HWCPAS_READ_OCTAL to SNOR_HWCAPS_READ_OCTAL.
Signed-off-by: NBean Huo <beanhuo@micron.com>
Reviewed-by: NTudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@collabora.com>