From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 00/21] sf: Tunning spi-flash layer
Date: Fri, 30 Oct 2015 21:30:22 +0100 [thread overview]
Message-ID: <201510302130.23053.marex@denx.de> (raw)
In-Reply-To: <CAD6G_RQBX4UzP_LZ6gV2EM2RxrNYoOtHom2nQtfd8WNEoLZFuw@mail.gmail.com>
On Friday, October 30, 2015 at 09:02:15 PM, Jagan Teki wrote:
> Hi Simon,
>
> On 30 October 2015 at 04:55, Simon Glass <sjg@chromium.org> wrote:
> > Hi Jagan,
> >
> > On 28 October 2015 at 13:08, Jagan Teki <jteki@openedev.com> wrote:
> >> Hi Simon,
> >>
> >> On 29 October 2015 at 00:17, Simon Glass <sjg@chromium.org> wrote:
> >> > Hi Jagan,
> >> >
> >> > On 19 October 2015 at 03:28, Jagan Teki <jteki@openedev.com> wrote:
> >> >> Hi Simon,
> >> >>
> >> >> On 19 October 2015 at 01:57, Simon Glass <sjg@chromium.org> wrote:
> >> >>> Hi Jagan,
> >> >>>
> >> >>> On 12 October 2015 at 09:00, Jagan Teki <jteki@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 ?
next prev parent reply other threads:[~2015-10-30 20:30 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-12 15:00 [U-Boot] [PATCH v4 00/21] sf: Tunning spi-flash layer Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 01/21] spi: zynq_spi: Remove unneeded headers Jagan Teki
2015-10-25 7:32 ` Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 02/21] sf: Return bank_sel, if flash->bank_curr == bank_sel Jagan Teki
2015-10-25 7:33 ` Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 03/21] sf: Add spi_flash_read_bar Jagan Teki
2015-10-25 7:35 ` Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 04/21] sf: Optimize BAR write code Jagan Teki
2015-10-25 7:36 ` Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 05/21] sf: Make flash->flags use for generic usage Jagan Teki
2015-10-25 7:38 ` Jagan Teki
2015-11-16 2:59 ` Bin Meng
2015-11-18 1:14 ` Bin Meng
2015-11-18 1:27 ` Tom Rini
2015-11-18 6:58 ` Jagan Teki
2015-10-12 15:00 ` [U-Boot] [PATCH v4 06/21] sf: Update status reg check in spi_flash_cmd_wait_ready Jagan Teki
2015-10-25 7:39 ` Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 07/21] sf: Add FSR support to spi_flash_cmd_wait_ready Jagan Teki
2015-10-25 7:40 ` Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 08/21] sf: spi_flash_validate_params => spi_flash_scan Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 09/21] sf: Move spi_flash_scan code to sf_ops Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 10/21] sf: Move the read_id " Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 11/21] sf: Move BAR defined code at once place Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 12/21] sf: Use static for file-scope functions Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 13/21] sf: Fix Makefile Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 14/21] sf: Use simple name for register access functions Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 15/21] sf: Use flash function pointers in dm_spi_flash_ops Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 16/21] sf: Flash power up read-only based on idcode0 Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 17/21] sf: Use static for file-scope functions Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 18/21] sf: Remove unneeded header includes Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 19/21] sf: probe: Use spi_flash_scan in dm-spi-flash Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 20/21] sf: Re-factorize spi_flash_probe_tail code Jagan Teki
2015-10-12 15:01 ` [U-Boot] [PATCH v4 21/21] dm-sf: Re-factorize spi_flash_std_probe code Jagan Teki
2015-10-18 20:27 ` [U-Boot] [PATCH v4 00/21] sf: Tunning spi-flash layer Simon Glass
2015-10-19 9:28 ` Jagan Teki
2015-10-28 18:47 ` Simon Glass
2015-10-28 19:08 ` Jagan Teki
2015-10-29 23:25 ` Simon Glass
2015-10-30 20:02 ` Jagan Teki
2015-10-30 20:30 ` Marek Vasut [this message]
2015-10-30 20:33 ` Jagan Teki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201510302130.23053.marex@denx.de \
--to=marex@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox