Commit d66d3519 authored by Brian Norris's avatar Brian Norris
Browse files

Merge branch 'spinor' 

Addition of the spi-nor framework, plus updates to the ST SPI FSM
driver.
parents 6189cccb dc002f99

Documentation/devicetree/bindings/mtd/fsl-quadspi.txt

0 → 100644
+35 −0
Original line number Diff line number Diff line 
* Freescale Quad Serial Peripheral Interface(QuadSPI)



Required properties:

  - compatible : Should be "fsl,vf610-qspi"

  - reg : the first contains the register location and length,

          the second contains the memory mapping address and length

  - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"

  - interrupts : Should contain the interrupt for the device

  - clocks : The clocks needed by the QuadSPI controller

  - clock-names : the name of the clocks



Optional properties:

  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.

                              Each bus can be connected with two NOR flashes.

			      Most of the time, each bus only has one NOR flash

			      connected, this is the default case.

			      But if there are two NOR flashes connected to the

			      bus, you should enable this property.

			      (Please check the board's schematic.)



Example:



qspi0: quadspi@40044000 {

	compatible = "fsl,vf610-qspi";

	reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;

	reg-names = "QuadSPI", "QuadSPI-memory";

	interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;

	clocks = <&clks VF610_CLK_QSPI0_EN>,

		<&clks VF610_CLK_QSPI0>;

	clock-names = "qspi_en", "qspi";



	flash0: s25fl128s@0 {

		....

	};

};

Documentation/mtd/spi-nor.txt

0 → 100644
+62 −0
Original line number Diff line number Diff line 
                          SPI NOR framework

               ============================================



Part I - Why do we need this framework?

---------------------------------------



SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus

controller operates agnostic of the specific device attached. However, some

controllers (such as Freescale's QuadSPI controller) cannot easily handle

arbitrary streams of bytes, but rather are designed specifically for SPI NOR.



In particular, Freescale's QuadSPI controller must know the NOR commands to

find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of

opcodes, addresses, or data payloads; a SPI controller simply knows to send or

receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under

which the controller driver is aware of the opcodes, addressing, and other

details of the SPI NOR protocol.



Part II - How does the framework work?

--------------------------------------



This framework just adds a new layer between the MTD and the SPI bus driver.

With this new layer, the SPI NOR controller driver does not depend on the

m25p80 code anymore.



   Before this framework, the layer is like:



                   MTD

         ------------------------

                  m25p80

         ------------------------

	       SPI bus driver

         ------------------------

	        SPI NOR chip



   After this framework, the layer is like:

                   MTD

         ------------------------

              SPI NOR framework

         ------------------------

                  m25p80

         ------------------------

	       SPI bus driver

         ------------------------

	       SPI NOR chip



  With the SPI NOR controller driver (Freescale QuadSPI), it looks like:

                   MTD

         ------------------------

              SPI NOR framework

         ------------------------

                fsl-quadSPI

         ------------------------

	       SPI NOR chip



Part III - How can drivers use the framework?

---------------------------------------------



The main API is spi_nor_scan(). Before you call the hook, a driver should

initialize the necessary fields for spi_nor{}. Please see

drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c

when you want to write a new driver for a SPI NOR controller.

drivers/mtd/Kconfig

+2 −0
Original line number Diff line number Diff line
@@ -321,6 +321,8 @@ source "drivers/mtd/onenand/Kconfig" 


source "drivers/mtd/lpddr/Kconfig"



source "drivers/mtd/spi-nor/Kconfig"



source "drivers/mtd/ubi/Kconfig"



endif # MTD

drivers/mtd/Makefile

+1 −0
Original line number Diff line number Diff line
@@ -32,4 +32,5 @@ inftl-objs := inftlcore.o inftlmount.o 


obj-y		+= chips/ lpddr/ maps/ devices/ nand/ onenand/ tests/



obj-$(CONFIG_MTD_SPI_NOR)	+= spi-nor/

obj-$(CONFIG_MTD_UBI)		+= ubi/

drivers/mtd/devices/Kconfig

+2 −2
Original line number Diff line number Diff line
@@ -80,7 +80,7 @@ config MTD_DATAFLASH_OTP 


config MTD_M25P80

	tristate "Support most SPI Flash chips (AT26DF, M25P, W25X, ...)"

	depends on SPI_MASTER

	depends on SPI_MASTER && MTD_SPI_NOR

	help

	  This enables access to most modern SPI flash chips, used for

	  program and data storage.   Series supported include Atmel AT26DF,
@@ -212,7 +212,7 @@ config MTD_DOCG3 


config MTD_ST_SPI_FSM

	tristate "ST Microelectronics SPI FSM Serial Flash Controller"

	depends on ARM || SH

	depends on ARCH_STI

	help

	  This provides an MTD device driver for the ST Microelectronics

	  SPI Fast Sequence Mode (FSM) Serial Flash Controller and support