mtd: spi-nor: add a new framework for SPI NOR

1.) Why add a new framework for SPI NOR?
The SPI-NOR controller such as Freescale's Quadspi controller is working in a different way from the SPI bus. It should knows the NOR commands to find the right LUT sequence. Unfortunately, the current code can not meet this requirement.

2.) How does this patch set do?
This patch set adds a new spi-nor layer.
Before this patch, the layer is like:

                   MTD
         ------------------------
                  m25p80
         ------------------------
               spi bus driver
         ------------------------
                SPI NOR chip

   After this patch, the layer is like:
                   MTD
         ------------------------
                  spi-nor
         ------------------------
                  m25p80
         ------------------------
               spi bus driver
         ------------------------
               SPI NOR chip

With the spi-nor controller driver(Freescale Quadspi), it looks like:

                   MTD
         ------------------------
                  spi-nor
         ------------------------
                fsl-quadspi
         ------------------------
               SPI NOR chip

3.) more details
This patch set adds a new data structrue spi_nor{}, clones most the common
code to spi-nor.c. Add spi_nor_xfer_cfg {} for the fundamental primitives:
read_xfer/write_xfer.

Make the m25p80.c/fsl_quaspi.c use the new APIs.

4.) Change log:
v3 --> v4:
[1] move the wait_till_ready to the @read hook.
[2] convert to linux-doc style comment.
[3] remove the some DT property for QuadSPI driver, such as "fsl,nor-size".
[4] others

v2 --> v3:
[1] add prepare/unprepare hooks for spi_nor{}.
[2] add a new "priv" field for spi_nor{}.
[3] add the Freescale Quadspi driver which supports the Quad read by default.

v1 --> v2:
[1] follow Angus's advice, add more hooks and data structrures.
[2] others.

Huang Shijie (7):
mtd: spi-nor: copy the SPI NOR commands to a new header file
mtd: spi-nor: add the basic data structures
mtd: spi-nor: add the framework for SPI NOR
mtd: m25p80: use the SPI nor framework
mtd: spi-nor: add a helper to find the spi_device_id
Documentation: add the binding file for Freescale QuadSPI driver
mtd: spi-nor: Add Freescale QuadSPI driver

 .../devicetree/bindings/mtd/fsl-quadspi.txt        |   26 +
 drivers/mtd/Kconfig                                |    2 +
 drivers/mtd/Makefile                               |    1 +
 drivers/mtd/devices/Kconfig                        |    2 +-
 drivers/mtd/devices/m25p80.c                       | 1275 ++------------------
 drivers/mtd/spi-nor/Kconfig                        |   12 +
 drivers/mtd/spi-nor/Makefile                       |    2 +
 drivers/mtd/spi-nor/fsl-quadspi.c                  |  957 +++++++++++++++
 drivers/mtd/spi-nor/spi-nor.c                      | 1093 +++++++++++++++++
 include/linux/mtd/spi-nor.h                        |  194 +++
 10 files changed, 2387 insertions(+), 1177 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/Kconfig
 create mode 100644 drivers/mtd/spi-nor/Makefile
 create mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c
 create mode 100644 drivers/mtd/spi-nor/spi-nor.c
 create mode 100644 include/linux/mtd/spi-nor.h

Hi,

Quoted 29 lines · Huang Shijie

1.) Why add a new framework for SPI NOR?
The SPI-NOR controller such as Freescale's Quadspi controller is working in a different way from the SPI bus. It should knows the NOR commands to find the right LUT sequence. Unfortunately, the current code can not meet this requirement.

2.) How does this patch set do?

    This patch set adds a new spi-nor layer.
    Before this patch, the layer is like:

                    MTD
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                 SPI NOR chip

    After this patch, the layer is like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                SPI NOR chip

Quoted 8 lines

   With the spi-nor controller driver(Freescale Quadspi), it looks like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                 fsl-quadspi
          ------------------------
                SPI NOR chip

I'm new to this thread, may be I'll ask basic questions.
1) what does m25p80 contains with your new framework - will excludes quad stuff if they add

2) I didn't understand why the controller driver fsl-quadspi will be in mtd becuase as it's (q)spi driver
may does flash or non-flash functionalities if ie, the case should be part of drivers/spi/*

3) Can you explain your framework precisely take an example of like spi_controller_A with spi_flash_A
and qspi_controller_B and qspi_flash_B - how will this new framework operates.

? 2014?01?16? 03:15, Jagan Teki ??:

Quoted 36 lines

Hi,

Quoted 32 lines · Huang Shijie

1.) Why add a new framework for SPI NOR?
The SPI-NOR controller such as Freescale's Quadspi controller is
working
in a different way from the SPI bus. It should knows the NOR commands
to
find the right LUT sequence. Unfortunately, the current code can not
meet
this requirement.

2.) How does this patch set do?

    This patch set adds a new spi-nor layer.
    Before this patch, the layer is like:

                    MTD
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                 SPI NOR chip

    After this patch, the layer is like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                SPI NOR chip

Quoted 10 lines

Quoted 9 lines

   With the spi-nor controller driver(Freescale Quadspi), it looks like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                 fsl-quadspi
          ------------------------
                SPI NOR chip

Quoted 3 lines

I'm new to this thread, may be I'll ask basic questions.
1) what does m25p80 contains with your new framework - will excludes quad stuff if they add

sorry, i do not understand your meaning.

do you think the m25p80 can not support the quad read after this patch set?

Quoted 4 lines

2) I didn't understand why the controller driver fsl-quadspi will be in mtd becuase as it's (q)spi driver
may does flash or non-flash functionalities if ie, the case should be part of drivers/spi/*

Please read this thread, Mark though it should be spi nor driver:

http://marc.info/?l=linux-arm-kernel&m=137782885415953&w=2

Quoted 5 lines

3) Can you explain your framework precisely take an example of like spi_controller_A with spi_flash_A
and qspi_controller_B and qspi_flash_B - how will this new framework operates.

The framework is just cloned from the m25p80.c, and extract the common code, and provides more
hooks such as

@prepare/unpreare: used to do some work before or after the
read/write/erase/lock/unlock.
@read_xfer/write_xfer: We can use these two hooks to code all
the following hooks if the driver tries to implement them by itself.
@read_reg: used to read the registers, such as read status register,
read configure register.
@write_reg: used to write the registers, such as write enable,
erase sector.
@read_id: read out the ID info.
@wait_till_ready: wait till the NOR becomes ready. @read: read out the data from the NOR.
@write: write data to the NOR.
@erase: erase a sector of the NOR.

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

    After this patch, the layer is like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                SPI NOR chip

Just for looking on your new framework, is that above link correct. I guess it should be MTD -- m25p80 -- spi-nor -- spi bus driver -- SPI NOR chip

Quoted 9 lines

Quoted 5 lines

3) Can you explain your framework precisely take an example of like spi_controller_A with spi_flash_A
and qspi_controller_B and qspi_flash_B - how will this new framework operates.

The framework is just cloned from the m25p80.c, and extract the common code, and provides more
hooks such as

Quoted 15 lines

@prepare/unpreare: used to do some work before or after the
read/write/erase/lock/unlock.
@read_xfer/write_xfer: We can use these two hooks to code all
the following hooks if the driver tries to implement them by itself.
@read_reg: used to read the registers, such as read status register,
read configure register.
@write_reg: used to write the registers, such as write enable,
erase sector.
@read_id: read out the ID info.
@wait_till_ready: wait till the NOR becomes ready. @read: read out the data from the NOR.
@write: write data to the NOR.
@erase: erase a sector of the NOR.

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 11 lines · Jagan Teki

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

    After this patch, the layer is like:
                    MTD
          ------------------------
                   spi-nor
          ------------------------
                   m25p80
          ------------------------
                spi bus driver
          ------------------------
                SPI NOR chip

Quoted 2 lines

Just for looking on your new framework, is that above link correct. I guess it should be MTD -- m25p80 -- spi-nor -- spi bus driver -- SPI NOR chip

I do not think so.
The spi-nor layer does not contact with the spi bus driver directly.

Quoted 26 lines

Quoted 10 lines

Quoted 6 lines

3) Can you explain your framework precisely take an example of like spi_controller_A with spi_flash_A
and qspi_controller_B and qspi_flash_B - how will this new framework operates.

The framework is just cloned from the m25p80.c, and extract the common code, and provides more
hooks such as

Quoted 15 lines

@prepare/unpreare: used to do some work before or after the
read/write/erase/lock/unlock.
@read_xfer/write_xfer: We can use these two hooks to code all
the following hooks if the driver tries to implement them by itself.
@read_reg: used to read the registers, such as read status register,
read configure register.
@write_reg: used to write the registers, such as write enable,
erase sector.
@read_id: read out the ID info.
@wait_till_ready: wait till the NOR becomes ready. @read: read out the data from the NOR.
@write: write data to the NOR.
@erase: erase a sector of the NOR.

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Quoted 8 lines

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 3 lines

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Quoted 8 lines · Jagan Teki

Quoted 8 lines

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 7 lines

Quoted 3 lines

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only need to add a NOR device node in the device tree. In the probe, it will call the m25p80.c to probe the NOR device.

But if we connect other device to it. you should set another device node for it.

I am not sure if your controller driver can works as the spi-imx.c

Quoted 16 lines · Huang Shijie

Quoted 8 lines · Jagan Teki

Quoted 8 lines

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 7 lines

Quoted 3 lines

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Quoted 7 lines

Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only need to add a NOR device node in the device tree. In the probe, it will call the m25p80.c to probe the NOR device.

But if we connect other device to it. you should set another device node for it.

I am not sure if your controller driver can works as the spi-imx.c

My question here was - this new framework suggest to write a two different controller
drivers one is for non spi-nor and spi-nor models? do you agree that?

And also one important note from your design was spi-nor mode is completely bypassing
Linux spi core is that the good idea?

From: Jagan Teki [mailto:jagannadh.teki at gmail.com]

I feel these are good points to discuss all.
1. With new framework seems like we need two separate controller drivers one for non spi-nor and one for spi-nor with single controller hw
2. With spi-nor implementation though the hw is spi complaint but the sw is completely ignoring the Linux SPI core interaction.

I feel above two points are technically wrong - Please correct me if am wrong but need all developers will join..thanks!

Hi Shijie,

Quoted 1 line

From: Jagan Teki [mailto:jagannadh.teki at gmail.com]

[...]

Quoted 10 lines

I feel these are good points to discuss all.
1. With new framework seems like we need two separate controller drivers one for non spi-nor and one for spi-nor with single controller hw
2. With spi-nor implementation though the hw is spi complaint but the sw is completely ignoring the Linux SPI core interaction.

I feel above two points are technically wrong - Please correct me if am wrong but need all developers will join..thanks!

I have been following this patch-set from sometime, And I think point (2) has been discussed back and forth in multiple times in earlier discussions. So, Is it possible for you to summarize point (2) with all pros-n-cons ?

- A README will helpful to clear all doubts and will ease your implementation as well.
- It will also help in reducing turn-around time to get this framework in acceptable state and still keep it generic enough.

You can submit the README as Documentation/mtd/spi-nor.txt

Quoted 18 lines · Jagan Teki

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 6 lines

Quoted 3 lines

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only need to add a NOR device node in the device tree. In the probe, it will call the m25p80.c to probe the NOR device.

Quoted 3 lines

But if we connect other device to it. you should set another device node for it.

I am not sure if your controller driver can works as the spi-imx.c

My question here was - this new framework suggest to write a two different controller
drivers one is for non spi-nor and spi-nor models? do you agree that?

And also one important note from your design was spi-nor mode is completely bypassing
Linux spi core is that the good idea?

? 2014?01?17? 16:39, Jagan Teki ??:

Quoted 30 lines

Quoted 28 lines · Huang Shijie

Quoted 16 lines · Jagan Teki

Quoted 10 lines

Quoted 3 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

Quoted 5 lines

You can use the framework for B2. But for B1, you should not use the framework,
since this framework is just for the SPI-NOR. If you do not connected with
a NOR, i think it's better to code another driver for your controller.

Quoted 3 lines

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only
need to add a NOR device node in the device tree. In the probe, it will call
the m25p80.c to probe the NOR device.

Quoted 8 lines

Quoted 4 lines

But if we connect other device to it. you should set another device node for it.

I am not sure if your controller driver can works as the spi-imx.c

My question here was - this new framework suggest to write a two different controller
drivers one is for non spi-nor and spi-nor models? do you agree that?

If your controller can either connects to a NOR, or can connects to other devices, it means your controller is a _BUS_.
You just need to write the bus driver for your controller, such as the spi-imx.c and drivers/bus/imx-weim.c do.

Since you have connect a device to your controller. you also need to write a driver for your device, such as the m25p80.c is
for your spi nor device.

Just think about that how do you code your driver for SPI NOR _without_ this framework:
do your driver need to call the m25p80.c? if you do call the m25p80.c, you actually write your so-called "two drivers" :)

This framework does nSPot change any logic for the current kernel, except adding a layer. With the new layer, we can code the
driver for the controllers which is a SPI-NOR controller, not a SPI bus controller.

Quoted 5 lines

And also one important note from your design was spi-nor mode is completely bypassing
Linux spi core is that the good idea?

yes. I think it's a good idea.

As Mark even pointed, the freescale's Quadspi controller is not a SPI controller, it is a SPI-NOR controller, it does _not_ need the LINUX SPI core.

Quoted 4 lines

Just think about that how do you code your driver for SPI NOR _without_ this framework:
do your driver need to call the m25p80.c? if you do call the m25p80.c, you actually write your so-called "two drivers" :)

I'm still not convinced here, sorry!
Let me explain more with example, Just take your (q)spi controller as an example B_FSL1 designed with - serial flash
B_FSL2 designed with - touch screen

With this design If we follow current we just need one controller driver (drivers/spi/spi-fsl.c)
to serve touch screen and serial flash from upper layers.

MTD core Input core
------------- -------------------------------
m25p80.c spi touchscreen driver (drivers/input/touchscreen)
----------------------------------------------------
SPI core
----------------------------------------------------
controller driver (drivers/spi/spi-fsl.)
----------------------------------------------------

But with your new SPI-NOR

MTD core
------------
SPI-NOR Input core
----------- ------------------
fsl-quadspi.c spi touchscreen driver (drivers/input/touchscreen)
---------------- ------------------------------

                         SPI Core
                         -----------------------------
                         controller driver (drivers/spi/spi-fsl.c)
                         -----------------------------------------

Here see we have two separate drivers for the same controller as it offers two functionalities. and also it never talk to Linux SPI subsystem which is not a good for me as intern hw is SPI-based it must talk to subsystem to make use of Linux SPI API's.

And also you mentioned SPI-NOR controller is not a SPI controller what does that means because it's a NOR flash which is of SPI protocol based.

I understand that your framework doing good things in matured manner, but seems like it's confuse to me to follow common standards - Just my opinion, may be I'm incorrect.

One more thing question - I have 1-wire spi controller which I was used for flash in
one board and keyboard in another board, so if I follow your framework I need to write
a driver in drivers/mtd/spi-nor/foo-spi.c and one more in drivers/spi/spi-foo.c - correct?

Quoted 11 lines · Huang Shijie

Quoted 10 lines · Jagan Teki

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

     After this patch, the layer is like:
                     MTD
           ------------------------
                    spi-nor
           ------------------------
                    m25p80
           ------------------------
                 spi bus driver
           ------------------------
                 SPI NOR chip

Quoted 4 lines

Quoted 2 lines

Just for looking on your new framework, is that above link correct. I guess it should be MTD -- m25p80 -- spi-nor -- spi bus driver -- SPI NOR chip

I do not think so.
The spi-nor layer does not contact with the spi bus driver directly.

Yes - now I understand the flow from seeing the code.
With your new framework
1. not an exact spi-nor
have one controller driver at drivers/spi/* will register to spi core. have m25p80.c will scan the flash details from
drivers/mtd/spi-nor/spi-nor.c and
m25p80 will register the MTD core and for transfer calls m25p80
will calls spi core.
2. spi-nor style
have one controller driver at drivers/mtd/spi-nor/fsl-quadspi.c
will register MTD core
and scan the flash details from drivers/mtd/spi-nor/spi-nor.c and
for transfer will calls
through direct writel and readl with cmd+data fashion.

Correct me If my understanding was wrong.

Quoted 26 lines

Quoted 24 lines

Quoted 9 lines

Quoted 5 lines

3) Can you explain your framework precisely take an example of like spi_controller_A with spi_flash_A
and qspi_controller_B and qspi_flash_B - how will this new framework operates.

The framework is just cloned from the m25p80.c, and extract the common code, and provides more
hooks such as

Quoted 15 lines

@prepare/unpreare: used to do some work before or after the
read/write/erase/lock/unlock.
@read_xfer/write_xfer: We can use these two hooks to code all
the following hooks if the driver tries to implement them by itself.
@read_reg: used to read the registers, such as read status register,
read configure register.
@write_reg: used to write the registers, such as write enable,
erase sector.
@read_id: read out the ID info.
@wait_till_ready: wait till the NOR becomes ready. @read: read out the data from the NOR.
@write: write data to the NOR.
@erase: erase a sector of the NOR.

Quoted 2 lines

My basic question is like I have a qspi spi controller in my SOC and I designed two boards B1 and B2

Quoted 8 lines

okay.

Quoted 3 lines

B1 with quad spi controller connected with non-flash as a slave and B2 with quad spi controller connected
with quad flash as a slave.

You can use the framework for B2. But for B1, you should not use the framework, since this framework is just for the SPI-NOR. If you do not connected with a NOR, i think it's better to code another driver for your controller.

Means we have two separate controller drivers for same controller one with spi-nor and
another with spi is it?

Do you think this is a good idea, I understand you have a complete and well guided new
spi-nor framework.