Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 12 9月, 2015 2 次提交
    • 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
    • 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
  3. 03 9月, 2015 3 次提交
  5. 07 8月, 2015 8 次提交
  7. 21 7月, 2015 1 次提交
  9. 24 6月, 2015 1 次提交
  11. 07 5月, 2015 1 次提交
  13. 31 3月, 2015 2 次提交
  15. 06 2月, 2015 4 次提交
  17. 21 1月, 2015 1 次提交
    • F
      mtd: fsl-quadspi: Fix module unbound · cfe4af3a
      由 Fabio Estevam 提交于 
      When removing the fsl-quadspi module and running 'cat /proc/mtd' afterwards,
we see garbage data like:

$ rmmod  fsl-quadspi
$ cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00000000 00000000 "(null)"
mtd0: 00000000 00000000 "(null)"
mtd0: 00000000 00000000 "(null)"
...
mtd0: a22296c6c756e28 00000000 "(null)"
mtd0: a22296c6c756e28 3064746d "(null)"

If we continue doing multiple module load/unload operations, then it will also
lead to a kernel crash.

The reason for this is due to the wrong mtd index used in
mtd_device_unregister() in the remove function.

We need to keep the mtd unregister index aligned with the one used in the probe
function, which means we need to take into account the 'has_second_chip'
property. By doing so we can guarantee that the mtd index is the same in the
registration and unregistration functions.

With this patch applied we can load/unload the fsl-quadspi driver several times
and it will result in no crash.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NHuang Shijie <shijie.huang@intel.com>
Tested-by: NFrank Li <Frank.Li@freescale.com>
Acked-by: NAllen Xu <han.xu@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      cfe4af3a
  19. 16 1月, 2015 1 次提交
  21. 01 12月, 2014 1 次提交
  23. 05 11月, 2014 1 次提交
  25. 22 10月, 2014 2 次提交
  27. 20 10月, 2014 1 次提交
  29. 18 10月, 2014 1 次提交
  31. 16 4月, 2014 1 次提交
  33. 15 4月, 2014 3 次提交
    • B
      mtd: spi-nor: unify read opcode variants with ST SPI FSM · 58b89a1f
      由 Brian Norris 提交于 
      serial_flash_cmds.h defines our opcodes a little differently. Let's
borrow its naming, since it's borrowed from the SFDP standard, and it's
more extensible.

This prepares us for merging serial_flash_cmds.h and spi-nor.h opcode
listing.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NHuang Shijie <b32955@freescale.com>
      58b89a1f
    • B
      mtd: spi-nor: re-name OPCODE_* to SPINOR_OP_* · b02e7f3e
      由 Brian Norris 提交于 
      Qualify these with a better namespace, and prepare them for use in more
drivers.
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
Reviewed-by: NMarek Vasut <marex@denx.de>
Acked-by: NHuang Shijie <b32955@freescale.com>
      b02e7f3e
    • H
      mtd: spi-nor: Add Freescale QuadSPI driver · e46ecda7
      由 Huang Shijie 提交于 
      (0) What is the QuadSPI controller?

    The QuadSPI(Quad Serial Peripheral Interface) acts as an interface to
    one single or two external serial flash devices, each with up to 4
    bidirectional data lines.

(1) The QuadSPI controller is driven by the LUT(Look-up Table) registers.
    The LUT registers are a look-up-table for sequences of instructions.
    A valid sequence consists of four LUT registers.

(2) The definition of the LUT register shows below:

    ---------------------------------------------------
    | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 |
    ---------------------------------------------------

    There are several types of INSTRx, such as:
	CMD	: the SPI NOR command.
	ADDR	: the address for the SPI NOR command.
	DUMMY	: the dummy cycles needed by the SPI NOR command.
	....

    There are several types of PADx, such as:
	PAD1	: use a singe I/O line.
	PAD2	: use two I/O lines.
	PAD4	: use quad I/O lines.
	....

(3) Test this driver with the JFFS2 and UBIFS:

    For jffs2:
    -------------
	#flash_eraseall /dev/mtd0
	#mount -t jffs2 /dev/mtdblock0 tmp
	#bonnie++ -d tmp -u 0 -s 10 -r 5

    For ubifs:
    -------------
	#flash_eraseall /dev/mtd0
	#ubiattach /dev/ubi_ctrl -m 0
	#ubimkvol /dev/ubi0 -N test -m
	#mount -t ubifs ubi0:test tmp
	#bonnie++ -d tmp -u 0 -s 10 -r 5
Signed-off-by: NHuang Shijie <b32955@freescale.com>
Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      e46ecda7