Browse Source

Documentation: spi-nor: rewrite some portions

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Brian Norris 11 years ago
parent
commit
254592db61
1 changed files with 20 additions and 17 deletions
  1. 20 17
      Documentation/mtd/spi-nor.txt

+ 20 - 17
Documentation/mtd/spi-nor.txt

@@ -1,19 +1,23 @@
                           SPI NOR framework
                           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?
 Part II - How does the framework work?
--------------------------------------
+--------------------------------------
 
 
 This framework just adds a new layer between the MTD and the SPI bus driver.
 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
 With this new layer, the SPI NOR controller driver does not depend on the
@@ -40,7 +44,7 @@ m25p80 code anymore.
          ------------------------
          ------------------------
 	       SPI NOR chip
 	       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
                    MTD
          ------------------------
          ------------------------
               SPI NOR framework
               SPI NOR framework
@@ -49,11 +53,10 @@ m25p80 code anymore.
          ------------------------
          ------------------------
 	       SPI NOR chip
 	       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.