Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 2月, 2016 1 次提交
  3. 27 1月, 2016 1 次提交
  5. 16 1月, 2016 1 次提交
  7. 07 1月, 2016 1 次提交
  9. 06 1月, 2016 2 次提交
  11. 19 12月, 2015 1 次提交
  13. 10 12月, 2015 1 次提交
  15. 05 12月, 2015 2 次提交
  17. 02 12月, 2015 1 次提交
  19. 21 11月, 2015 1 次提交
  21. 20 11月, 2015 2 次提交
  23. 19 11月, 2015 1 次提交
  25. 17 11月, 2015 1 次提交
  27. 12 11月, 2015 4 次提交
  29. 27 10月, 2015 1 次提交
    • H
      mtd: fsl-quadspi: fix macro collision problems with READ/WRITE · 04850c4d
      由 Han Xu 提交于 
      Change the READ/WRITE to FSL_READ/FSL_WRITE to resolve any possible
namespace collisions with READ/WRITE macros (e.g., from <linux/fs.h>).

Problems have been seen, for example, on mips:

>> drivers/mtd/spi-nor/fsl-quadspi.c:186:5: error: 'LUT_0' undeclared (first use in this function)
      ((LUT_##ins) << INSTR0_SHIFT))
        ^
>> drivers/mtd/spi-nor/fsl-quadspi.c:188:30: note: in expansion of macro 'LUT0'

On SPARC:

drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error: 'LUT_0' undeclared (first use in this function)
drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error: pasting "LUT_" and "(" does not give a valid preprocessing token
drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error: implicit declaration of function 'LUT_'

And surely on others.

Fixes: d26a22d0 ("mtd: fsl-quadspi: allow building for other ARCHes with COMPILE_TEST")
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NHan Xu <b45815@freescale.com>
[Brian: rewrote commit description]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      04850c4d
  31. 20 10月, 2015 4 次提交
  33. 14 10月, 2015 7 次提交
  35. 13 10月, 2015 1 次提交
  37. 30 9月, 2015 3 次提交
    • B
      mtd: spi-nor: add support for w25q128fw · 4404bd74
      由 Brian Norris 提交于 
      Tested only with single I/O, but the datasheet says it supports dual and
quad.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      4404bd74
    • F
      mtd: spi-nor: scale up timeout for full-chip erase · 09b6a377
      由 Furquan Shaikh 提交于 
      This patch fixes timeout issues seen on large NOR flash (e.g., 16MB
w25q128fw) when using ioctl(MEMERASE) with offset=0 and length=16M. The
input parameters matter because spi_nor_erase() uses a different code
path for full-chip erase, where we use the SPINOR_OP_CHIP_ERASE (0xc7)
opcode.

Fix: use a different timeout for full-chip erase than for other
commands.

While most operations can be expected to perform relatively similarly
across a variety of NOR flash types and sizes (and therefore might as
well use a similar timeout to keep things simple), full-chip erase is
unique, because the time it typically takes to complete:
(1) is much larger than most operations and
(2) scales with the size of the flash.

Let's base our timeout on the original comments stuck here -- that a 2MB
flash requires max 40s to erase.

Small survey of a few flash datasheets I have lying around:

  Chip         Size (MB)   Max chip erase (seconds)
  ----         --------    ------------------------
  w25q32fw     4           50
  w25q64cv     8           30
  w25q64fw     8           100
  w25q128fw    16          200
  s25fl128s    16          ~256
  s25fl256s    32          ~512

From this data, it seems plenty sufficient to say we need to wait for
40 seconds for each 2MB of flash.

After this change, it might make some sense to decrease the timeout for
everything else, as even the most extreme operations (single block
erase?) shouldn't take more than a handful of seconds. But for safety,
let's leave it as-is. It's only an error case, after all, so we don't
exactly need to optimize it.
Signed-off-by: NFurquan Shaikh <furquan@google.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      09b6a377
    • Y
      mtd: spi-nor: Add support for sst25wf040b · c887be71
      由 Yao Yuan 提交于 
      It is a 512KiB flash with 4 KiB erase sectors.
Signed-off-by: NYuan Yao <yao.yuan@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      c887be71
  39. 29 9月, 2015 1 次提交
  41. 12 9月, 2015 3 次提交
    • J
      mtd: spi-nor: Zap unneeded write_enable from write_reg · f9f3ce83
      由 Jagan Teki 提交于 
      The 'write_enable' argument is unused and unneeded, so remove it from
the API.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Han Xu <han.xu@freescale.com>
[Brian: fixed for nxp-spifi.c]
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      f9f3ce83
    • J
      mtd: spi-nor: Use write_sr for write status · fd725234
      由 Jagan Teki 提交于 
      Use existing write_sr() call instead of decoding and
calling nor->write_reg separately.
Signed-off-by: NJagan Teki <jteki@openedev.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      fd725234
    • M
      mtd: spi-nor: Decouple SPI NOR's device_node from controller device · 11bff0b7
      由 Marek Vasut 提交于 
      The problem this patch is trying to address is such, that SPI NOR flash
devices attached to a dedicated SPI NOR controller cannot read their
properties from the associated struct device_node.

A couple of facts first:
1) Each SPI NOR flash has a struct spi_nor associated with it.
2) Each SPI NOR flash has certain device properties associated
   with it, for example the OF property 'm25p,fast-read' is a
   good pick. These properties are used by the SPI NOR core to
   select which opcodes are sent to such SPI NOR flash. These
   properties are coming from spi_nor .dev->of_node .

The problem is, that for SPI NOR controllers, the struct spi_nor .dev
element points to the struct device of the SPI NOR controller, not the
SPI NOR flash. Therefore, the associated dev->of_node also is the
one of the controller and therefore the SPI NOR core code is trying to
parse the SPI NOR controller's properties, not the properties of the
SPI NOR flash.

Note: The m25p80 driver is not affected, because the controller and
      the flash are the same device, so the associated device_node
      of the controller and the flash are the same.

This patch adjusts the SPI NOR core such that the device_node is not
picked from spi_nor .dev directly, but from a new separate spi_nor
.flash_node element. This let's the SPI NOR controller drivers set up
a different spi_nor .flash_node element for each SPI NOR flash.

This patch also fixes the controller drivers to be compatible with
this modification and correctly set the spi_nor .flash_node element.

This patch is inspired by 5844feea
mtd: nand: add common DT init code
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      11bff0b7