diff options
author | Brian Norris <computersforpeace@gmail.com> | 2014-04-08 20:17:04 -0700 |
---|---|---|
committer | Brian Norris <computersforpeace@gmail.com> | 2014-04-14 11:23:01 -0700 |
commit | 254592db612aeb55d80399a04995b68f7da48c99 (patch) | |
tree | b123f4ff44d473400578363cd9cdb8a9a780c51f /Documentation/mtd | |
parent | 58b89a1f4c2a65b10b8f7b90b6ff2161b19bb0d1 (diff) |
Documentation: spi-nor: rewrite some portions
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Diffstat (limited to 'Documentation/mtd')
-rw-r--r-- | Documentation/mtd/spi-nor.txt | 37 |
1 files changed, 20 insertions, 17 deletions
diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt index 294d5b06f892..548d6306ebca 100644 --- a/Documentation/mtd/spi-nor.txt +++ b/Documentation/mtd/spi-nor.txt @@ -1,19 +1,23 @@ SPI NOR framework ============================================ -Part I - why we need this framework? -------------------------------------- +Part I - Why do we need this framework? +--------------------------------------- -The SPI bus controller only deals with the byte stream. -Some controller does not works like a SPI bus controller, it works -like a SPI NOR controller instead, such as the Freescale's QuadSPI controller. +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. -The Freescale's QuadSPI controller should know the NOR commands to -find the right LUT sequence. Unfortunately, the old code can not meet -this requirement. +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 @@ -40,7 +44,7 @@ m25p80 code anymore. ------------------------ SPI NOR chip - With the SPI NOR controller driver(Freescale QuadSPI), it looks like: + With the SPI NOR controller driver (Freescale QuadSPI), it looks like: MTD ------------------------ SPI NOR framework @@ -49,11 +53,10 @@ m25p80 code anymore. ------------------------ SPI NOR chip -Part III - How can the drivers use the framework -------------------------------------- +Part III - How can drivers use the framework? +--------------------------------------------- -The main API is the spi_nor_scan(). Before you call the hook, you should -initialize the necessary fields for spi_nor{}. -Please see the drivers/mtd/spi-nor/spi-nor.c for detail. -Please also reference to the fsl-quadspi.c when you want to write a new driver -for a SPI NOR controller. +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. |