sf: Tunning spi-flash layer

- Removed unneeded inclusion of header files
- Add "Xilinx" on license text

Signed-off-by Jagan Teki <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

If computed bank_sel is same as flash->bank_curr which is computed at probe time, then return the bank_sel instead of zero.

Signed-off-by Jagan Teki <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

Add spi_flash_read_bar function for reading bar and discovering bar commands at probe time.

Signed-off-by Jagan Teki <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

---

Optimized spi-flash bar writing code and also removed unnecessary bank_sel in read_ops.

Signed-off-by Jagan Teki <[email protected]>

Cc Simon Glass <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

---

Use the flash->flags for generic usage, not only for dm-spi-flash, this will be used for future flag additions.

Signed-off-by Jagan Teki <[email protected]>

[Correct the spi flash flags detect logic]

Signed-off-by Bin Meng <[email protected]>

Tested-by Bin Meng <[email protected]>

---

Use the flash->flags for generic usage, not only for dm-spi-flash, this will be used for future flag additions.

Signed-off-by Jagan Teki <[email protected]>

[Correct the spi flash flags detect logic]

Signed-off-by Bin Meng <[email protected]>

Tested-by Bin Meng <[email protected]>

---
Changes for v4:
- Fixed SNOR_F_SST_WR
Changes for v3, v2:
- none

 drivers/mtd/spi/sf_internal.h |  4 ++++
 drivers/mtd/spi/sf_probe.c    | 10 +++++-----
 include/spi_flash.h           |  4 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

drivers/mtd/spi/sf_internal.h +4 -0

index 9c95d56..53998fc 100644
@@ -51,6 +51,10 @@ enum {
 
 #define SST_WR         (SST_BP | SST_WP)
 
+enum spi_nor_option_flags {
+       SNOR_F_SST_WR           = (1 << 0),
+};
+
 #define SPI_FLASH_3B_ADDR_LEN          3
 #define SPI_FLASH_CMD_LEN              (1 + SPI_FLASH_3B_ADDR_LEN)
 #define SPI_FLASH_16MB_BOUN            0x1000000

drivers/mtd/spi/sf_probe.c +5 -5

index f17ec17..2634e90 100644
@@ -163,15 +163,15 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
        flash->name = params->name;
        flash->memory_map = spi->memory_map;
        flash->dual_flash = flash->spi->option;
-#ifdef CONFIG_DM_SPI_FLASH
-       flash->flags = params->flags;
-#endif
 
        /* Assign spi_flash ops */
 #ifndef CONFIG_DM_SPI_FLASH
        flash->write = spi_flash_cmd_write_ops;
 #if defined(CONFIG_SPI_FLASH_SST)
-       if (params->flags & SST_WR) {
+       if (params->flags & SST_WR)
+               flash->flags |= SNOR_F_SST_WR;
+
+       if (params->flags & SNOR_F_SST_WR) {
                if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
                        flash->write = sst_write_bp;
                else

@@ -466,7 +466,7 @@ int spi_flash_std_write(struct udevice *dev, u32 offset, size_t len,
        struct spi_flash *flash = dev_get_uclass_priv(dev);
 
 #if defined(CONFIG_SPI_FLASH_SST)
-       if (flash->flags & SST_WR) {
+       if (flash->flags & SNOR_F_SST_WR) {
                if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
                        return sst_write_bp(flash, offset, len, buf);
                else

include/spi_flash.h +1 -1

index 3b2d555..8d85468 100644
@@ -38,10 +38,10 @@ struct spi_slave;
  *
  * @spi:               SPI slave
  * @dev:               SPI flash device
- * @flags:             Indication of spi flash flags
  * @name:              Name of SPI flash
  * @dual_flash:                Indicates dual flash memories - dual stacked, parallel
  * @shift:             Flash shift useful in dual parallel
+ * @flags:             Indication of spi flash flags
  * @size:              Total flash size
  * @page_size:         Write (page) size
  * @sector_size:       Sector size

@@ -67,11 +67,11 @@ struct spi_flash {
        struct spi_slave *spi;
 #ifdef CONFIG_DM_SPI_FLASH
        struct udevice *dev;

Hi Jagan,

Quoted 7 lines · Jagan Teki

Use the flash->flags for generic usage, not only for dm-spi-flash, this will be used for future flag additions.

Signed-off-by Jagan Teki <[email protected]>

[Correct the spi flash flags detect logic]

Signed-off-by Bin Meng <[email protected]>

Tested-by Bin Meng <[email protected]>

Quoted 6 lines

---
Changes for v4:
- Fixed SNOR_F_SST_WR
Changes for v3, v2:
- none

It turns out this patch breaks the Intel Crown Bay SPI flash. I compared my original submitted patch with this patch you applied, and surprisingly found there are differences ...

My version is http://patchwork.ozlabs.org/patch/517704/
You version below seems to modify some places which you thought would be correct, but that's unfortunately wrong. If you reworked my patch, I think you should remove at least my "Tested-by:" tag and ask me to retest.

Can you please help me understand what happened? I expected that you should just grab my version and include it in your patch series.

Hi Jagan,

Quoted 27 lines · Bin Meng

Hi Jagan,

Quoted 7 lines · Jagan Teki

Use the flash->flags for generic usage, not only for dm-spi-flash, this will be used for future flag additions.

Signed-off-by Jagan Teki <[email protected]>

[Correct the spi flash flags detect logic]

Signed-off-by Bin Meng <[email protected]>

Tested-by Bin Meng <[email protected]>

Quoted 6 lines

---
Changes for v4:
- Fixed SNOR_F_SST_WR
Changes for v3, v2:
- none

It turns out this patch breaks the Intel Crown Bay SPI flash. I compared my original submitted patch with this patch you applied, and surprisingly found there are differences ...

My version is http://patchwork.ozlabs.org/patch/517704/
You version below seems to modify some places which you thought would be correct, but that's unfortunately wrong. If you reworked my patch, I think you should remove at least my "Tested-by:" tag and ask me to retest.

Quoted 3 lines

Can you please help me understand what happened? I expected that you should just grab my version and include it in your patch series.

I see you were replying yesterday, but did not see any response on this one.

Hi Jagan,

Quoted 7 lines · Jagan Teki

Use the flash->flags for generic usage, not only for dm-spi-flash, this will be used for future flag additions.

Signed-off-by Jagan Teki <[email protected]>

[Correct the spi flash flags detect logic]

Signed-off-by Bin Meng <[email protected]>

Tested-by Bin Meng <[email protected]>

Quoted 6 lines

---
Changes for v4:
- Fixed SNOR_F_SST_WR
Changes for v3, v2:
- none

It turns out this patch breaks the Intel Crown Bay SPI flash. I compared my original submitted patch with this patch you applied, and surprisingly found there are differences ...

My version is http://patchwork.ozlabs.org/patch/517704/
You version below seems to modify some places which you thought would be correct, but that's unfortunately wrong. If you reworked my patch, I think you should remove at least my "Tested-by:" tag and ask me to retest.

Can you please help me understand what happened? I expected that you should just grab my version and include it in your patch series.

Quoted 81 lines

 drivers/mtd/spi/sf_internal.h |  4 ++++
 drivers/mtd/spi/sf_probe.c    | 10 +++++-----
 include/spi_flash.h           |  4 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

drivers/mtd/spi/sf_internal.h +4 -0

index 9c95d56..53998fc 100644
@@ -51,6 +51,10 @@ enum {
 
 #define SST_WR         (SST_BP | SST_WP)
 
+enum spi_nor_option_flags {
+       SNOR_F_SST_WR           = (1 << 0),
+};
+
 #define SPI_FLASH_3B_ADDR_LEN          3
 #define SPI_FLASH_CMD_LEN              (1 + SPI_FLASH_3B_ADDR_LEN)
 #define SPI_FLASH_16MB_BOUN            0x1000000

drivers/mtd/spi/sf_probe.c +5 -5

index f17ec17..2634e90 100644
@@ -163,15 +163,15 @@ static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
        flash->name = params->name;
        flash->memory_map = spi->memory_map;
        flash->dual_flash = flash->spi->option;
-#ifdef CONFIG_DM_SPI_FLASH
-       flash->flags = params->flags;
-#endif
 
        /* Assign spi_flash ops */
 #ifndef CONFIG_DM_SPI_FLASH
        flash->write = spi_flash_cmd_write_ops;
 #if defined(CONFIG_SPI_FLASH_SST)
-       if (params->flags & SST_WR) {
+       if (params->flags & SST_WR)
+               flash->flags |= SNOR_F_SST_WR;
+
+       if (params->flags & SNOR_F_SST_WR) {
                if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
                        flash->write = sst_write_bp;
                else

@@ -466,7 +466,7 @@ int spi_flash_std_write(struct udevice *dev, u32 offset, size_t len,
        struct spi_flash *flash = dev_get_uclass_priv(dev);
 
 #if defined(CONFIG_SPI_FLASH_SST)
-       if (flash->flags & SST_WR) {
+       if (flash->flags & SNOR_F_SST_WR) {
                if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
                        return sst_write_bp(flash, offset, len, buf);
                else

include/spi_flash.h +2 -2

index 3b2d555..8d85468 100644
@@ -38,10 +38,10 @@ struct spi_slave;
  *
  * @spi:               SPI slave
  * @dev:               SPI flash device
- * @flags:             Indication of spi flash flags
  * @name:              Name of SPI flash
  * @dual_flash:                Indicates dual flash memories - dual stacked, parallel
  * @shift:             Flash shift useful in dual parallel
+ * @flags:             Indication of spi flash flags
  * @size:              Total flash size
  * @page_size:         Write (page) size
  * @sector_size:       Sector size

@@ -67,11 +67,11 @@ struct spi_flash {
        struct spi_slave *spi;
 #ifdef CONFIG_DM_SPI_FLASH
        struct udevice *dev;
-       u16 flags;
 #endif
        const char *name;
        u8 dual_flash;
        u8 shift;
+       u16 flags;
 

include/spi_flash.h struct spi_flash {

Quoted 3 lines

include/spi_flash.h +0 -1

        u32 size;
        u32 page_size;
--

Current flash wait_ready logic is not modular to add new register status check, hence updated the status check for adding few more register checks in future.

Below are the sf speed runs with 'sf update' on whole flash, 16MiB.

=> sf update 0x100 0x0 0x1000000
device 0 whole chip
16777216 bytes written, 0 bytes skipped in 59.564s, speed 289262 B/s

=> sf update 0x100 0x0 0x1000000
device 0 whole chip
16777216 bytes written, 0 bytes skipped in 62.549s, speed 275036 B/s

=> sf update 0x100 0x0 0x1000000
device 0 whole chip
16777216 bytes written, 0 bytes skipped in 61.276s, speed 284359 B/s

Signed-off-by Jagan Teki <[email protected]>

Cc Simon Glass <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

Cc Stefan Roese <[email protected]>

Cc Tom Warren <[email protected]>

Cc Tom Rini <[email protected]>

Tested-by Jagan Teki <[email protected]>

Tested-by Bin Meng <[email protected]>

---

This patch adds flag status register reading support to spi_flash_cmd_wait_ready.

Signed-off-by Jagan Teki <[email protected]>

Cc Simon Glass <[email protected]>

Cc Marek Vasut <[email protected]>

Cc Michal Simek <[email protected]>

Cc Siva Durga Prasad Paladugu <[email protected]>

Cc Stefan Roese <[email protected]>

Cc Tom Warren <[email protected]>

Cc Tom Rini <[email protected]>

Cc Hou Zhiqiang <[email protected]>

Tested-by Jagan Teki <[email protected]>

Tested-by Bin Meng <[email protected]>

---

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

Testing:

$ git clone git://git.denx.de/u-boot-spi.git
$ cd u-boot-spi
$ git checkout -b spi-nor-tune origin/next-spi-nor-tune

thanks!
Jagan.

Jagan Teki (21):
spi: zynq_spi: Remove unneeded headers
sf: Return bank_sel, if flash->bank_curr == bank_sel
sf: Add spi_flash_read_bar
sf: Optimize BAR write code
sf: Make flash->flags use for generic usage
sf: Update status reg check in spi_flash_cmd_wait_ready
sf: Add FSR support to spi_flash_cmd_wait_ready
sf: spi_flash_validate_params => spi_flash_scan
sf: Move spi_flash_scan code to sf_ops
sf: Move the read_id code to sf_ops
sf: Move BAR defined code at once place
sf: Use static for file-scope functions
sf: Fix Makefile
sf: Use simple name for register access functions
sf: Use flash function pointers in dm_spi_flash_ops
sf: Flash power up read-only based on idcode0
sf: Use static for file-scope functions
sf: Remove unneeded header includes
sf: probe: Use spi_flash_scan in dm-spi-flash
sf: Re-factorize spi_flash_probe_tail code
dm-sf: Re-factorize spi_flash_std_probe code

 drivers/mtd/spi/Makefile      |   6 +-
 drivers/mtd/spi/sf_internal.h |  57 ++---
 drivers/mtd/spi/sf_ops.c      | 488 +++++++++++++++++++++++++++++++++++-------
 drivers/mtd/spi/sf_probe.c    | 446 ++++++--------------------------------
 drivers/spi/zynq_spi.c        |   6 +-
 include/spi_flash.h           |  19 +-
 6 files changed, 494 insertions(+), 528 deletions(-)

--
1.9.1

Hi Jagan,

Quoted 29 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Quoted 7 lines

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

Sorry if I am misunderstanding your intent here.

Quoted 42 lines

Testing:

$ git clone git://git.denx.de/u-boot-spi.git
$ cd u-boot-spi
$ git checkout -b spi-nor-tune origin/next-spi-nor-tune

thanks!
Jagan.

Jagan Teki (21):
spi: zynq_spi: Remove unneeded headers
sf: Return bank_sel, if flash->bank_curr == bank_sel
sf: Add spi_flash_read_bar
sf: Optimize BAR write code
sf: Make flash->flags use for generic usage
sf: Update status reg check in spi_flash_cmd_wait_ready
sf: Add FSR support to spi_flash_cmd_wait_ready
sf: spi_flash_validate_params => spi_flash_scan
sf: Move spi_flash_scan code to sf_ops
sf: Move the read_id code to sf_ops
sf: Move BAR defined code at once place
sf: Use static for file-scope functions
sf: Fix Makefile
sf: Use simple name for register access functions
sf: Use flash function pointers in dm_spi_flash_ops
sf: Flash power up read-only based on idcode0
sf: Use static for file-scope functions
sf: Remove unneeded header includes
sf: probe: Use spi_flash_scan in dm-spi-flash
sf: Re-factorize spi_flash_probe_tail code
dm-sf: Re-factorize spi_flash_std_probe code

 drivers/mtd/spi/Makefile      |   6 +-
 drivers/mtd/spi/sf_internal.h |  57 ++---
 drivers/mtd/spi/sf_ops.c      | 488 +++++++++++++++++++++++++++++++++++-------
 drivers/mtd/spi/sf_probe.c    | 446 ++++++--------------------------------
 drivers/spi/zynq_spi.c        |   6 +-
 include/spi_flash.h           |  19 +-
 6 files changed, 494 insertions(+), 528 deletions(-)

--
1.9.1

Hi Simon,

Quoted 40 lines · Simon Glass

Hi Jagan,

Quoted 29 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Quoted 7 lines

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

Quoted 5 lines

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------
                        cmd_sf
    -----------------------------------------------------
                        spi_flash
    -----------------------------------------------------
                        MTD Core
    -----------------------------------------------------
                        sf-uclass
    -----------------------------------------------------
                        SPI-NOR
    -----------------------------------------------------
        spi-nor-flash           drivers/mtd/spi/*
    -----------------------------------------------------
        spi-uclass
    -----------------------------------------------------
        drivers/spi/*
    -----------------------------------------------------

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Please let me know for any more comments.

Quoted 44 lines

Sorry if I am misunderstanding your intent here.

Quoted 40 lines

Testing:

$ git clone git://git.denx.de/u-boot-spi.git
$ cd u-boot-spi
$ git checkout -b spi-nor-tune origin/next-spi-nor-tune

thanks!
Jagan.

Jagan Teki (21):
spi: zynq_spi: Remove unneeded headers
sf: Return bank_sel, if flash->bank_curr == bank_sel
sf: Add spi_flash_read_bar
sf: Optimize BAR write code
sf: Make flash->flags use for generic usage
sf: Update status reg check in spi_flash_cmd_wait_ready
sf: Add FSR support to spi_flash_cmd_wait_ready
sf: spi_flash_validate_params => spi_flash_scan
sf: Move spi_flash_scan code to sf_ops
sf: Move the read_id code to sf_ops
sf: Move BAR defined code at once place
sf: Use static for file-scope functions
sf: Fix Makefile
sf: Use simple name for register access functions
sf: Use flash function pointers in dm_spi_flash_ops
sf: Flash power up read-only based on idcode0
sf: Use static for file-scope functions
sf: Remove unneeded header includes
sf: probe: Use spi_flash_scan in dm-spi-flash
sf: Re-factorize spi_flash_probe_tail code
dm-sf: Re-factorize spi_flash_std_probe code

 drivers/mtd/spi/Makefile      |   6 +-
 drivers/mtd/spi/sf_internal.h |  57 ++---
 drivers/mtd/spi/sf_ops.c      | 488 +++++++++++++++++++++++++++++++++++-------
 drivers/mtd/spi/sf_probe.c    | 446 ++++++--------------------------------
 drivers/spi/zynq_spi.c        |   6 +-
 include/spi_flash.h           |  19 +-
 6 files changed, 494 insertions(+), 528 deletions(-)

Quoted 2 lines

Quoted 2 lines

--
1.9.1

-- Jagan.

Hi Jagan,

Quoted 104 lines · Jagan Teki

Hi Simon,

Quoted 40 lines · Simon Glass

Hi Jagan,

Quoted 29 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Quoted 7 lines

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

Quoted 5 lines

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------
                        cmd_sf
    -----------------------------------------------------
                        spi_flash
    -----------------------------------------------------
                        MTD Core
    -----------------------------------------------------
                        sf-uclass
    -----------------------------------------------------
                        SPI-NOR
    -----------------------------------------------------
        spi-nor-flash           drivers/mtd/spi/*
    -----------------------------------------------------
        spi-uclass
    -----------------------------------------------------
        drivers/spi/*
    -----------------------------------------------------

Quoted 5 lines

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Please let me know for any more comments.

Perhaps another way of asking this is, what is the plan to remove the non-DM code from SF or at least stop adding new features to it.

Quoted 10 lines

Quoted 10 lines

Sorry if I am misunderstanding your intent here.

Quoted 5 lines

Testing:

$ git clone git://git.denx.de/u-boot-spi.git
$ cd u-boot-spi
$ git checkout -b spi-nor-tune origin/next-spi-nor-tune

Hi Simon,

Quoted 107 lines · Simon Glass

Hi Jagan,

Quoted 104 lines · Jagan Teki

Hi Simon,

Quoted 40 lines · Simon Glass

Hi Jagan,

Quoted 29 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Quoted 7 lines

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

Quoted 5 lines

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------
                        cmd_sf
    -----------------------------------------------------
                        spi_flash
    -----------------------------------------------------
                        MTD Core
    -----------------------------------------------------
                        sf-uclass
    -----------------------------------------------------
                        SPI-NOR
    -----------------------------------------------------
        spi-nor-flash           drivers/mtd/spi/*
    -----------------------------------------------------
        spi-uclass
    -----------------------------------------------------
        drivers/spi/*
    -----------------------------------------------------

Quoted 8 lines

Quoted 5 lines

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Please let me know for any more comments.

Perhaps another way of asking this is, what is the plan to remove the non-DM code from SF or at least stop adding new features to it.

Sorry I didn't understand "remove non-dm code" or either I missed something here.

The plan is not to remove any code intentionally it's about following feature additions
1) Tuning up spi-flash framework: Separating Core spi-flash code and interface code between spi-flash vs spi drivers
2) Adding MTD core support to spi-flash core (no spi_flash ops - mtd_ops will use)
3) Introduce spi-nor core (spi-flash core becomes spi-nor) and new spi-nor controller drivers are part of this like fsl_qspi or etc. spi-nor controllers and interface code between spi-flash vs spi-drivers become UCLASS_SPI_NOR

Agenda is to add SPI-NOR framework(almost similar to Linux) with driver model(as UCLASS_SPI_NOR)

-----------------------------------------------------------------------------------------------
cmd_spi cmd_sf
-------|----------------------------------------------------------------------------------------
| spi_flash
-------|----------------------------------------------------------------------------------------
| MTD Core
-------|----------------------------------------------------------------------------------------
| spi-nor-uclass
-------|----------------------------------------------------------------------------------------
| SPI-NOR Core (spi-nor.c)
-------|-----------------------------------------------------------------------------------------

        |          |=========spi-nor-flash

drivers/mtd/spi/fsl_qspi
| | (m25p80.c)
(fsl-quadspi.c)
--------|-------V-----------------------------------------------------------------------------------
spi-uclass
--------------------------------------------------------------------------------------------------
drivers/spi/*
-----------------------------------------------------

Let me know for any more comments?

Hi Jagan,

Quoted 158 lines · Jagan Teki

Hi Simon,

Quoted 107 lines · Simon Glass

Hi Jagan,

Quoted 104 lines · Jagan Teki

Hi Simon,

Quoted 40 lines · Simon Glass

Hi Jagan,

Quoted 29 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series.
- BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface (interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:
dm:
text data bss dec hex filename
354820 12016 221112 587948 8f8ac u-boot
non-dm
text data bss dec hex filename
354317 11876 221124 587317 8f635 u-boot

Quoted 7 lines

Before:
dm
text data bss dec hex filename
354878 12016 221096 587990 8f8d6 u-boot
non-dm
text data bss dec hex filename
354447 11876 221124 587447 8f6b7 u-boot

Quoted 5 lines

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------
                        cmd_sf
    -----------------------------------------------------
                        spi_flash
    -----------------------------------------------------
                        MTD Core
    -----------------------------------------------------
                        sf-uclass
    -----------------------------------------------------
                        SPI-NOR
    -----------------------------------------------------
        spi-nor-flash           drivers/mtd/spi/*
    -----------------------------------------------------
        spi-uclass
    -----------------------------------------------------
        drivers/spi/*
    -----------------------------------------------------

Quoted 8 lines

Quoted 5 lines

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Please let me know for any more comments.

Perhaps another way of asking this is, what is the plan to remove the non-DM code from SF or at least stop adding new features to it.

Sorry I didn't understand "remove non-dm code" or either I missed something here.

The plan is not to remove any code intentionally it's about following feature additions
1) Tuning up spi-flash framework: Separating Core spi-flash code and interface code between spi-flash vs spi drivers
2) Adding MTD core support to spi-flash core (no spi_flash ops - mtd_ops will use)
3) Introduce spi-nor core (spi-flash core becomes spi-nor) and new spi-nor controller drivers are part of this like fsl_qspi or etc. spi-nor controllers and interface code between spi-flash vs spi-drivers become UCLASS_SPI_NOR

Agenda is to add SPI-NOR framework(almost similar to Linux) with driver model(as UCLASS_SPI_NOR)

-----------------------------------------------------------------------------------------------
cmd_spi cmd_sf
-------|----------------------------------------------------------------------------------------
| spi_flash
-------|----------------------------------------------------------------------------------------
| MTD Core
-------|----------------------------------------------------------------------------------------
| spi-nor-uclass
-------|----------------------------------------------------------------------------------------
| SPI-NOR Core (spi-nor.c)
-------|-----------------------------------------------------------------------------------------

        |          |=========spi-nor-flash

drivers/mtd/spi/fsl_qspi
| | (m25p80.c)
(fsl-quadspi.c)
--------|-------V-----------------------------------------------------------------------------------
spi-uclass
--------------------------------------------------------------------------------------------------
drivers/spi/*
-----------------------------------------------------

Quoted 1 line

Let me know for any more comments?

This is quite a big topic. Also you are the maintainer, not me. So I don't want to interfere. It's just that I am conscious that my SPI flash conversion was incomplete, in that:

- it still provides the old API (and we need to keep this until every board migrates)
- it still uses struct spi_flash as a parameter, when it should really use struct udevice
- the concept of chip select number and bus number are still present, but in the end these should just be devices

So I'm keen to keep moving things in the direction of 'fully migrated'.

Adding a new feature like SPI nor seems like a good oppty to encourage people to move over to driver model - .e.g if the new feature is only available with driver model.

Hi Simon,

Quoted 228 lines · Simon Glass

Hi Jagan,

Quoted 205 lines · Jagan Teki

Hi Simon,

Quoted 138 lines · Simon Glass

Hi Jagan,

Quoted 135 lines · Jagan Teki

Hi Simon,

Quoted 49 lines · Simon Glass

Hi Jagan,

Quoted 46 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series. - BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface

(interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:

dm:
text data bss dec hex filename

354820 12016 221112 587948 8f8ac u-boot

non-dm

text data bss dec hex filename

354317 11876 221124 587317 8f635 u-boot

Before:
dm

text data bss dec hex filename

354878 12016 221096 587990 8f8d6 u-boot

non-dm

text data bss dec hex filename

Quoted 7 lines

Quoted 1 line

354447 11876 221124 587447 8f6b7 u-boot

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------
    
                        cmd_sf
    
    -----------------------------------------------------
    
                        spi_flash
    
    -----------------------------------------------------
    
                        MTD Core
    
    -----------------------------------------------------
    
                        sf-uclass
    
    -----------------------------------------------------
    
                        SPI-NOR
    
    -----------------------------------------------------
    
        spi-nor-flash           drivers/mtd/spi/*
    
    -----------------------------------------------------
    
        spi-uclass
    
    -----------------------------------------------------
    
        drivers/spi/*
    
    -----------------------------------------------------

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Quoted 4 lines

Quoted 1 line

Please let me know for any more comments.

Perhaps another way of asking this is, what is the plan to remove the non-DM code from SF or at least stop adding new features to it.

Sorry I didn't understand "remove non-dm code" or either I missed something here.

The plan is not to remove any code intentionally it's about following feature additions
1) Tuning up spi-flash framework: Separating Core spi-flash code and interface code between spi-flash vs spi drivers
2) Adding MTD core support to spi-flash core (no spi_flash ops - mtd_ops will use)
3) Introduce spi-nor core (spi-flash core becomes spi-nor) and new spi-nor controller drivers are part of this like fsl_qspi or etc. spi-nor controllers and interface code between spi-flash vs spi-drivers become UCLASS_SPI_NOR

Agenda is to add SPI-NOR framework(almost similar to Linux) with driver model(as UCLASS_SPI_NOR)

------------------------------------------------------------------------
-----------------------

cmd_spi cmd_sf

-------|----------------------------------------------------------------
------------------------

| spi_flash

-------|----------------------------------------------------------------
------------------------

| MTD Core

-------|----------------------------------------------------------------
------------------------

| spi-nor-uclass

-------|----------------------------------------------------------------
------------------------

        |                                            SPI-NOR Core
        |                                            (spi-nor.c)

-------|----------------------------------------------------------------
-------------------------

        |          |=========spi-nor-flash

drivers/mtd/spi/fsl_qspi

| | (m25p80.c)

(fsl-quadspi.c)

--------|-------V-------------------------------------------------------
----------------------------

spi-uclass

Quoted 8 lines

------------------------------------------------------------------------
--------------------------

drivers/spi/*

-----------------------------------------------------

Let me know for any more comments?

This is quite a big topic. Also you are the maintainer, not me. So I don't want to interfere. It's just that I am conscious that my SPI flash conversion was incomplete, in that:

- it still provides the old API (and we need to keep this until every board migrates)
- it still uses struct spi_flash as a parameter, when it should really use struct udevice
- the concept of chip select number and bus number are still present, but in the end these should just be devices

Quoted 5 lines

So I'm keen to keep moving things in the direction of 'fully migrated'.

Adding a new feature like SPI nor seems like a good oppty to encourage people to move over to driver model - .e.g if the new feature is only available with driver model.

Just park this spi-nor stuff, once I send all patches will discuss more.

This series is for code re-factorization like separating spi-flash core functionality vs spi-driver interface from spi-flash core. Did you find any wrong on this?

Quoted 237 lines · Jagan Teki

Hi Simon,

Quoted 233 lines · Simon Glass

Hi Jagan,

Quoted 205 lines · Jagan Teki

Hi Simon,

Quoted 138 lines · Simon Glass

Hi Jagan,

Quoted 135 lines · Jagan Teki

Hi Simon,

Quoted 49 lines · Simon Glass

Hi Jagan,

Quoted 46 lines · Jagan Teki

Previous version link:
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/233262

spi-flash layer need to tune a lot for better code handling and to sync with Linux spi-nor. So below areas got updated in this series. - BAR handling
- spi_flash_cmd_wait_ready updates.
- Separate core spi-flash handling and spi-flash interface

(interface between spi drivers vs spi-flash layer)

Currently I'm working on spi-nor framework for u-boot which is slighly same as Linux spi-nor core with addition of u-boot driver model to it.

This series will be starting point to add spi-nor functionalities.

TODO:
- MTD core addition to spi-flash layer.
- spi-nor core addition.

Code sizes:
After:

dm:
text data bss dec hex filename

354820 12016 221112 587948 8f8ac u-boot

non-dm

text data bss dec hex filename

354317 11876 221124 587317 8f635 u-boot

Before:
dm

text data bss dec hex filename

354878 12016 221096 587990 8f8d6 u-boot

non-dm

text data bss dec hex filename

Quoted 7 lines

Quoted 1 line

354447 11876 221124 587447 8f6b7 u-boot

I don't think you should be adding new features to the non-driver-model SPI flash code. We are supposed to be migrating everything to driver model, so it would be better to move your boards over, and then work to deprecate and remove the old code. Adding new features to it sends the wrong message.

spi-flash core code doesn't require to add driver model, and cmd_sf to spi-flash code is already supporting driver model.

OK, let me explain in-detail.

Code in sf_probe.c supports both dm and non dm-spi-flash and flash initialization code using
spi_flash_validate_params. sf.c acts as interface between spi drivers vs spi-flash code.
So the spi-flash initialization code(part of sf_probe) and code in sf_ops are commonly categorized as spi-flash core code and this will not require driver model, so-that the dm drivers will simply use this common code for spi-flash core functionality.

This patch series will separate all the necessary existing code into core and spi-flash vs spi drivers interface code. So at ends
- sf_probe is simply the copy of sf.c and dm and non-dm spi-flash code so this will acts a spi-flash vs spi drivers interface. (which has dm and non-dm as same as before)
- sf_ops is core spi-flash functionality.

On top of this I'm adding actual spi-nor core code, where sf_ops.c will become spi-nor.c and sf_probe.c will become spi-nor-flash.c.
- spi-nor.c: Core SPI NOR
- spi-nor-flash: spi drivers vs spi-nor interface (which has dm and non-dm as same as before)

The reason for adding this spi-nor is to move flash code from spi-drivers, example fsl_qspi and at the end this fsl_qspi will move from spi drivers to spi-nor that will be in driver model.

I'm simply adding new core functionality with adding new drivers as dm-driven, I don't think this will not effect/change the driver model growth.

View of spi-nor framework:

    -----------------------------------------------------

                        cmd_sf

    -----------------------------------------------------

                        spi_flash

    -----------------------------------------------------

                        MTD Core

    -----------------------------------------------------

                        sf-uclass

    -----------------------------------------------------

                        SPI-NOR

    -----------------------------------------------------

        spi-nor-flash           drivers/mtd/spi/*

    -----------------------------------------------------

        spi-uclass

    -----------------------------------------------------

        drivers/spi/*

    -----------------------------------------------------

drivers/mtd/spi/spi-nor.c: spi-nor core (not require to add dm) drivers/mtd/spi/spi-flash-nor.c: spi-nor to spi drivers interface (dm-driven) drivers/mtd/spi/fsl-quadspi.c: spi-nor controller driver (dm-driven)

Quoted 4 lines

Quoted 1 line

Please let me know for any more comments.

Perhaps another way of asking this is, what is the plan to remove the non-DM code from SF or at least stop adding new features to it.

Sorry I didn't understand "remove non-dm code" or either I missed something here.

The plan is not to remove any code intentionally it's about following feature additions
1) Tuning up spi-flash framework: Separating Core spi-flash code and interface code between spi-flash vs spi drivers
2) Adding MTD core support to spi-flash core (no spi_flash ops - mtd_ops will use)
3) Introduce spi-nor core (spi-flash core becomes spi-nor) and new spi-nor controller drivers are part of this like fsl_qspi or etc. spi-nor controllers and interface code between spi-flash vs spi-drivers become UCLASS_SPI_NOR

Agenda is to add SPI-NOR framework(almost similar to Linux) with driver model(as UCLASS_SPI_NOR)

------------------------------------------------------------------------
-----------------------

cmd_spi cmd_sf

-------|----------------------------------------------------------------
------------------------

| spi_flash

-------|----------------------------------------------------------------
------------------------

| MTD Core

-------|----------------------------------------------------------------
------------------------

| spi-nor-uclass

-------|----------------------------------------------------------------
------------------------

        |                                            SPI-NOR Core
        |                                            (spi-nor.c)

-------|----------------------------------------------------------------
-------------------------

        |          |=========spi-nor-flash

drivers/mtd/spi/fsl_qspi

| | (m25p80.c)

(fsl-quadspi.c)

--------|-------V-------------------------------------------------------
----------------------------

spi-uclass

Quoted 8 lines

------------------------------------------------------------------------
--------------------------

drivers/spi/*

-----------------------------------------------------

Let me know for any more comments?

This is quite a big topic. Also you are the maintainer, not me. So I don't want to interfere. It's just that I am conscious that my SPI flash conversion was incomplete, in that:

- it still provides the old API (and we need to keep this until every board migrates)
- it still uses struct spi_flash as a parameter, when it should really use struct udevice
- the concept of chip select number and bus number are still present, but in the end these should just be devices

So I'm keen to keep moving things in the direction of 'fully migrated'.

Adding a new feature like SPI nor seems like a good oppty to encourage people to move over to driver model - .e.g if the new feature is only available with driver model.

Quoted 5 lines

Just park this spi-nor stuff, once I send all patches will discuss more.

This series is for code re-factorization like separating spi-flash core functionality vs spi-driver interface from spi-flash core. Did you find any wrong on this?

Why don't we converge toward Linux's spi-nor stack instead ?