1*4882a593Smuzhiyun================= 2*4882a593SmuzhiyunSPI NOR framework 3*4882a593Smuzhiyun================= 4*4882a593Smuzhiyun 5*4882a593SmuzhiyunPart I - Why do we need this framework? 6*4882a593Smuzhiyun--------------------------------------- 7*4882a593Smuzhiyun 8*4882a593SmuzhiyunSPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus 9*4882a593Smuzhiyuncontroller operates agnostic of the specific device attached. However, some 10*4882a593Smuzhiyuncontrollers (such as Freescale's QuadSPI controller) cannot easily handle 11*4882a593Smuzhiyunarbitrary streams of bytes, but rather are designed specifically for SPI NOR. 12*4882a593Smuzhiyun 13*4882a593SmuzhiyunIn particular, Freescale's QuadSPI controller must know the NOR commands to 14*4882a593Smuzhiyunfind the right LUT sequence. Unfortunately, the SPI subsystem has no notion of 15*4882a593Smuzhiyunopcodes, addresses, or data payloads; a SPI controller simply knows to send or 16*4882a593Smuzhiyunreceive bytes (Tx and Rx). Therefore, we must define a new layering scheme under 17*4882a593Smuzhiyunwhich the controller driver is aware of the opcodes, addressing, and other 18*4882a593Smuzhiyundetails of the SPI NOR protocol. 19*4882a593Smuzhiyun 20*4882a593SmuzhiyunPart II - How does the framework work? 21*4882a593Smuzhiyun-------------------------------------- 22*4882a593Smuzhiyun 23*4882a593SmuzhiyunThis framework just adds a new layer between the MTD and the SPI bus driver. 24*4882a593SmuzhiyunWith this new layer, the SPI NOR controller driver does not depend on the 25*4882a593Smuzhiyunm25p80 code anymore. 26*4882a593Smuzhiyun 27*4882a593SmuzhiyunBefore this framework, the layer is like:: 28*4882a593Smuzhiyun 29*4882a593Smuzhiyun MTD 30*4882a593Smuzhiyun ------------------------ 31*4882a593Smuzhiyun m25p80 32*4882a593Smuzhiyun ------------------------ 33*4882a593Smuzhiyun SPI bus driver 34*4882a593Smuzhiyun ------------------------ 35*4882a593Smuzhiyun SPI NOR chip 36*4882a593Smuzhiyun 37*4882a593Smuzhiyun After this framework, the layer is like: 38*4882a593Smuzhiyun MTD 39*4882a593Smuzhiyun ------------------------ 40*4882a593Smuzhiyun SPI NOR framework 41*4882a593Smuzhiyun ------------------------ 42*4882a593Smuzhiyun m25p80 43*4882a593Smuzhiyun ------------------------ 44*4882a593Smuzhiyun SPI bus driver 45*4882a593Smuzhiyun ------------------------ 46*4882a593Smuzhiyun SPI NOR chip 47*4882a593Smuzhiyun 48*4882a593Smuzhiyun With the SPI NOR controller driver (Freescale QuadSPI), it looks like: 49*4882a593Smuzhiyun MTD 50*4882a593Smuzhiyun ------------------------ 51*4882a593Smuzhiyun SPI NOR framework 52*4882a593Smuzhiyun ------------------------ 53*4882a593Smuzhiyun fsl-quadSPI 54*4882a593Smuzhiyun ------------------------ 55*4882a593Smuzhiyun SPI NOR chip 56*4882a593Smuzhiyun 57*4882a593SmuzhiyunPart III - How can drivers use the framework? 58*4882a593Smuzhiyun--------------------------------------------- 59*4882a593Smuzhiyun 60*4882a593SmuzhiyunThe main API is spi_nor_scan(). Before you call the hook, a driver should 61*4882a593Smuzhiyuninitialize the necessary fields for spi_nor{}. Please see 62*4882a593Smuzhiyundrivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c 63*4882a593Smuzhiyunwhen you want to write a new driver for a SPI NOR controller. 64*4882a593SmuzhiyunAnother API is spi_nor_restore(), this is used to restore the status of SPI 65*4882a593Smuzhiyunflash chip such as addressing mode. Call it whenever detach the driver from 66*4882a593Smuzhiyundevice or reboot the system. 67