[U-Boot] [PATCH v4 00/21] sf: Tunning spi-flash layer
Simon Glass
sjg at chromium.org
Wed Oct 28 19:47:11 CET 2015
Hi Jagan,
On 19 October 2015 at 03:28, Jagan Teki <jteki at openedev.com> wrote:
> Hi Simon,
>
> On 19 October 2015 at 01:57, Simon Glass <sjg at chromium.org> wrote:
>> Hi Jagan,
>>
>> On 12 October 2015 at 09:00, Jagan Teki <jteki at 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 if I am misunderstanding your intent here.
>>
>>>
>>> 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
>
> -- Jagan.
Regards,
Simon
More information about the U-Boot
mailing list