litmus-rt.git/drivers/mtd/devices, branch master

Documentation: dt: mtd: replace "nor-jedec" binding with "jedec, spi-nor"

2015-05-15T20:04:00+00:00

In commit 8ff16cf77ce3 ("Documentation: devicetree: m25p80: add "nor-jedec"
binding"), we added a generic "nor-jedec" binding to catch all
mostly-compatible SPI NOR flash which can be detected via the READ ID
opcode (0x9F). This was discussed and reviewed at the time, however
objections have come up since then as part of this discussion:

  http://lkml.kernel.org/g/20150511224646.GJ32500@ld-irv-0074

It seems the parties involved agree that "jedec,spi-nor" does a better
job of capturing the fact that this is SPI-specific, not just any NOR
flash.

This binding was only merged for v4.1-rc1, so it's still OK to change
the naming.

At the same time, let's move the documentation to a better name.

Next up: stop referring to code (drivers/mtd/devices/m25p80.c) from the
documentation.

Signed-off-by: Brian Norris 
Cc: Marek Vasut 
Cc: Rafał Miłecki 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: devicetree@vger.kernel.org
Acked-by: Stephen Warren 
Acked-by: Geert Uytterhoeven 
Acked-by: Mark Rutland

mtd: m25p80: bind to "nor-jedec" ID, for auto-detection

2015-04-06T01:56:21+00:00

Use the new 'nor-jedec' binding to provide automatic detection of flash
that use the 0x9F READ ID opcode. This can help for use cases where
platforms just specify compatibility with "m25p80", and then see
messages like this:

  m25p80 spi32766.0: found s25fl256s1, expected m25p80

Instead, they can just specify the generic string and see this:

  m25p80 spi32766.0: s25fl256s1 (32768 Kbytes)

Also, update the language about m25p_ids[] to straighten out the
expectations here. We should no longer need to continuously grow the
m25p_ids[] table, and in fact, we might want to start removing entries
which are not used in device trees so far, so we can just default to
auto-detection as much as possible in the future.

Signed-off-by: Brian Norris 
Cc: Rafał Miłecki

mtd: docg3: remove invalid __exit annotations

2015-04-06T01:06:44+00:00

The .remove callback may be used when detaching a device via sysfs, so
we can't expect to free up this memory.

Signed-off-by: Brian Norris 
Acked-by: Robert Jarzmik

mtd: docg3: drop dead code

2015-03-11T22:21:19+00:00

If no devices were found, we would already have skipped over this code.

Detected by Coverity, CID #744270

Signed-off-by: Brian Norris 
Acked-by: Robert Jarzmik

mtd: block2mtd: wait until block devices are presented

2015-02-24T07:44:12+00:00

Ensures that block2mtd is triggered after the block devices are enumerated
at boot time.
This issue is seen on BCM2835 (Raspberry Pi) systems when mounting JFFS2
block2mtd filesystems, probably because of the delay on enumerating a USB
MMC card reader.

Signed-off-by: Felix Fietkau 
Signed-off-by: Rodrigo Freire 
Signed-off-by: Herton Krzesinski 
Signed-off-by: Brian Norris

mtd: st_spi_fsm: Fix [-Wsign-compare] build warning

2015-01-13T05:08:10+00:00

drivers/mtd/devices/st_spi_fsm.c:1647:17:
  warning: comparison between signed and unsigned integer expressions

Signed-off-by: Lee Jones 
Signed-off-by: Brian Norris

mtd: st_spi_fsm: Obtain and use EMI clock

2015-01-13T05:08:04+00:00

ST's Common Clk Framework is now available. This patch ensures the FSM
makes use of it by obtaining and enabling the EMI clock. If system fails
to provide the EMI clock, we bomb out.

Signed-off-by: Lee Jones 
Signed-off-by: Brian Norris

mtd: st_spi_fsm: Extend fsm_clear_fifo to handle unwanted bytes

2015-01-13T05:08:00+00:00

Under certain conditions, the SPI-FSM Controller can be left in a state where
the data FIFO is not entirely empty.  This can lead to problems where subsequent
data transfers appear to have been shifted by a number of unidentified bytes.

One simple example would be an errant FSM sequence which loaded more data to the
FIFO than was read by the host.  Another more interesting case results from an
obscure artefact in the FSM Controller.  When switching from data transfers in
x4 or x2 mode to data transfers in x1 mode, extraneous bytes will appear in the
FIFO, unless the previous data transfer was a multiple of 32 cycles (i.e. 8
bytes for x2, and 16 bytes for x4).  This applies equally whether FSM is being
operated directly by a S/W driver, or by the SPI boot-controller in FSM-Boot
mode.  Furthermore, data in the FIFO not only survive a transition between
FSM-Boot and FSM, but also a S/W reset of IP block [1].

By taking certain precautions, it is possible to prevent the driver from causing
this type of problem (e.g. ensuring that the host and programmed sequence
agree on the transfer size, and restricting transfer sizes to multiples of
32-cycles [2]).  However, at the point the driver is loaded, no assumptions can be
made regarding the state of the FIFO.  Even if previous S/W drivers have behaved
correctly, it is impossible to control the number of transactions serviced by
the controller operating in FSM-Boot.

To address this problem, we ensure the FIFO is cleared during initialisation,
before performing any FSM operations.  Previously, the fsm_clear_fifo() code was
capable of detecting and clearing any unwanted 32-bit words from the FIFO.  This
patch extends the capability to handle an arbitrary number of bytes present in
the FIFO [3].  Now that the issue is better understood, we also remove the calls
to fsm_clear_fifo() following the fsm_read() and fsm_write() operations.

The process of actually clearing the FIFO deserves a mention.  While the FIFO
may contain any number of bytes, the SPI_FAST_SEQ_STA register only reports the
number of complete 32-bit words present.  Furthermore, data can only be drained
from the FIFO by reading complete 32-bit words.  With this in mind, a two stage
process is used to the clear the FIFO:

    1. Read any complete 32-bit words from the FIFO, as reported by the
           SPI_FAST_SEQ_STA register.

    2. Mop up any remaining bytes.  At this point, it is not known if there
           are 0, 1, 2, or 3 bytes in the FIFO.  To handle all cases, a dummy
           FSM sequence is used to load one byte at a time, until a complete
           32-bit word is formed; at most, 4 bytes will need to be loaded.

[1] Although this issue has existed since early versions of the SPI-FSM
    controller, its full extent only emerged recently as a consequence of the
    targetpacks starting to use FSM-Boot(x4) as the default configuration.

[2] The requirement to restrict transfers to multiples of 32 cycles was found
    empirically back when DUAL and QUAD mode support was added.  The current
    analysis now gives a satisfactory explanation for this requirement.

[3] Theoretically, it is possible for the FIFO to contain an arbitrary number of
    bits.  However, since there are no known use-cases that leave incomplete
    bytes in the FIFO, only words and bytes are considered here.

Signed-off-by: Angus Clark 
Signed-off-by: Lee Jones 
Signed-off-by: Brian Norris

Merge tag 'for-linus-20141215' of git://git.infradead.org/linux-mtd

2014-12-17T17:59:26+00:00

Pull MTD updates from Brian Norris:
 "Summary:
   - Add device tree support for DoC3

   - SPI NOR:
        Refactoring, for better layering between spi-nor.c and its
        driver users (e.g., m25p80.c)

        New flash device support

        Support 6-byte ID strings

   - NAND:
        New NAND driver for Allwinner SoC's (sunxi)

        GPMI NAND: add support for raw (no ECC) access, for testing
        purposes

        Add ATO manufacturer ID

        A few odd driver fixes

   - MTD tests:
        Allow testers to compensate for OOB bitflips in oobtest

        Fix a torturetest regression

   - nandsim: Support longer ID byte strings

  And more"

* tag 'for-linus-20141215' of git://git.infradead.org/linux-mtd: (63 commits)
  mtd: tests: abort torturetest on erase errors
  mtd: physmap_of: fix potential NULL dereference
  mtd: spi-nor: allow NULL as chip name and try to auto detect it
  mtd: nand: gpmi: add raw oob access functions
  mtd: nand: gpmi: add proper raw access support
  mtd: nand: gpmi: add gpmi_copy_bits function
  mtd: spi-nor: factor out write_enable() for erase commands
  mtd: spi-nor: add support for s25fl128s
  mtd: spi-nor: remove the jedec_id/ext_id
  mtd: spi-nor: add id/id_len for flash_info{}
  mtd: nand: correct the comment of function nand_block_isreserved()
  jffs2: Drop bogus if in comment
  mtd: atmel_nand: replace memcpy32_toio/memcpy32_fromio with memcpy
  mtd: cafe_nand: drop duplicate .write_page implementation
  mtd: m25p80: Add support for serial flash Spansion S25FL132K
  MTD: m25p80: fix inconsistency in m25p_ids compared to spi_nor_ids
  mtd: spi-nor: improve wait-till-ready timeout loop
  mtd: delete unnecessary checks before two function calls
  mtd: nand: omap: Fix NAND enumeration on 3430 LDP
  mtd: nand: add ATO manufacturer info
  ...

mtd: spi-nor: factor out write_enable() for erase commands

2014-12-01T08:19:03+00:00

write_enable() was being duplicated to both m25p80.c and fsl-quadspi.c.
But this should be handled within the spi-nor abstraction layer.

At the same time, let's add write_disable() after erasing, so we don't
leave the flash in a write-enabled state afterward.

Signed-off-by: Brian Norris 
Acked-by: Huang Shijie