sf: Tunning spi-flash layer

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?