On 31 October 2015 at 02:00, Marek Vasut <ma...@denx.de> wrote: > On Friday, October 30, 2015 at 09:02:15 PM, Jagan Teki wrote: >> Hi Simon, >> >> On 30 October 2015 at 04:55, Simon Glass <s...@chromium.org> wrote: >> > Hi Jagan, >> > >> > On 28 October 2015 at 13:08, Jagan Teki <jt...@openedev.com> wrote: >> >> Hi Simon, >> >> >> >> On 29 October 2015 at 00:17, Simon Glass <s...@chromium.org> wrote: >> >> > Hi Jagan, >> >> > >> >> > On 19 October 2015 at 03:28, Jagan Teki <jt...@openedev.com> wrote: >> >> >> Hi Simon, >> >> >> >> >> >> On 19 October 2015 at 01:57, Simon Glass <s...@chromium.org> wrote: >> >> >>> Hi Jagan, >> >> >>> >> >> >>> On 12 October 2015 at 09:00, Jagan Teki <jt...@openedev.com> wrote: >> >> >>>> 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 >> >> >>> >> >> >>> 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. >> >> > >> >> > 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? >> > >> > 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. >> >> 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 ?
Yes I'm trying for the same model with dm-driven (UCLASS_SPI_NOR) thanks! -- Jagan | openedev. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot