Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 1 | SPI NOR framework |
| 2 | ============================================ |
| 3 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 4 | Part I - Why do we need this framework? |
| 5 | --------------------------------------- |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 6 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 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. |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 11 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 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. |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 18 | |
| 19 | Part II - How does the framework work? |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 20 | -------------------------------------- |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 21 | |
| 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 |
| 24 | m25p80 code anymore. |
| 25 | |
| 26 | Before this framework, the layer is like: |
| 27 | |
| 28 | MTD |
| 29 | ------------------------ |
| 30 | m25p80 |
| 31 | ------------------------ |
| 32 | SPI bus driver |
| 33 | ------------------------ |
| 34 | SPI NOR chip |
| 35 | |
| 36 | After this framework, the layer is like: |
| 37 | MTD |
| 38 | ------------------------ |
| 39 | SPI NOR framework |
| 40 | ------------------------ |
| 41 | m25p80 |
| 42 | ------------------------ |
| 43 | SPI bus driver |
| 44 | ------------------------ |
| 45 | SPI NOR chip |
| 46 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 47 | With the SPI NOR controller driver (Freescale QuadSPI), it looks like: |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 48 | MTD |
| 49 | ------------------------ |
| 50 | SPI NOR framework |
| 51 | ------------------------ |
| 52 | fsl-quadSPI |
| 53 | ------------------------ |
| 54 | SPI NOR chip |
| 55 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 56 | Part III - How can drivers use the framework? |
| 57 | --------------------------------------------- |
Huang Shijie | 1ef3910 | 2014-02-28 15:58:00 +0800 | [diff] [blame] | 58 | |
Brian Norris | 254592db | 2014-04-08 20:17:04 -0700 | [diff] [blame] | 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. |