2 ============================================
4 Part I - Why do we need this framework?
5 ---------------------------------------
7 SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus
8 controller operates agnostic of the specific device attached. However, some
9 controllers (such as Freescale's QuadSPI controller) cannot easily handle
10 arbitrary streams of bytes, but rather are designed specifically for SPI NOR.
12 In particular, Freescale's QuadSPI controller must know the NOR commands to
13 find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of
14 opcodes, addresses, or data payloads; a SPI controller simply knows to send or
15 receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under
16 which the controller driver is aware of the opcodes, addressing, and other
17 details of the SPI NOR protocol.
19 Part II - How does the framework work?
20 --------------------------------------
22 This framework just adds a new layer between the MTD and the SPI bus driver.
23 With this new layer, the SPI NOR controller driver does not depend on the
26 Before this framework, the layer is like:
29 ------------------------
31 ------------------------
33 ------------------------
36 After this framework, the layer is like:
38 ------------------------
40 ------------------------
42 ------------------------
44 ------------------------
47 With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
49 ------------------------
51 ------------------------
53 ------------------------
56 Part III - How can drivers use the framework?
57 ---------------------------------------------
59 The main API is spi_nor_scan(). Before you call the hook, a driver should
60 initialize the necessary fields for spi_nor{}. Please see
61 drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
62 when you want to write a new driver for a SPI NOR controller.