All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update`
Date: Wed, 19 Dec 2012 17:42:13 -0600	[thread overview]
Message-ID: <1355960533.12062.16@snotra> (raw)
In-Reply-To: <CAPnjgZ0qWjZ+pLyoDzRMQ90nkOnRH30sskKdSPWYa4N5iTbmvA@mail.gmail.com> (from sjg@chromium.org on Wed Dec 19 17:20:07 2012)

On 12/19/2012 05:20:07 PM, Simon Glass wrote:
> Hi Wolfgang,
> 
> On Wed, Dec 19, 2012 at 3:10 PM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Simon Glass,
> >
> > In message <1348878482-1730-1-git-send-email-sjg@chromium.org> you  
> wrote:
> >> From: James Miller <jamesmiller@chromium.org>
> >>
> >> Output a progress update only at most 10 times per second, to avoid
> >> saturating (and waiting on) the console. Make the summary line
> >> to fit on a single line. Make sure that cursor sits at the end of
> >> each update line instead of the beginning.
> >>
> >> Sample output:
> >>
> >> SF: Detected W25Q32 with page size 4 KiB, total 4 MiB
> >> Update SPI
> >> 1331200 bytes written, 2863104 bytes skipped in 21.912s, speed  
> 199728 B/s
> >
> > I dislike making commands more verbose then needed, or helpful.  Of
> > course the latter may be considered a matter of taste, but first of
> > all you also add code size here for questionable benefit.
> >
> > I object against this patch:
> >
> > 1) I cannot see what is so special in the "sf" command that it needs
> >    such handling, while commands accessing NOR or NAND flash or
> >    SDCard or any other storage devices don't.
> >
> >    If there is an agreement that this feature should be added, then  
> it
> >    should be done in a general way that can be used everywhere.
> >
> >    [Note that I doubt that "if".]
> 
> Hmmm I suppose that is a good point. The main issue with SPI flash is
> that it is extremely slow, and writing a few MB can take a minute or
> so. The 'sf update' command was intended to do a smart update, and the
> progress is useful for that. Other storage types are not so bad.

NOR can be pretty slow as well -- and it does have a progress indicator  
in U-Boot (albeit a simpler one).

NAND has a progress meter on erase, and for larger transfers it could  
probably use one on read/write as well.

-Scott

  reply	other threads:[~2012-12-19 23:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-29  0:28 [U-Boot] [PATCH 1/2] spi: Add progress percentage and write speed to `sf update` Simon Glass
2012-09-29  0:28 ` [U-Boot] [PATCH 2/2] spi: Add SPI flash test Simon Glass
2012-10-01 17:32   ` Tom Rini
2012-10-08 23:00     ` Simon Glass
2012-10-08 23:03       ` Tom Rini
2012-12-19 23:12   ` Wolfgang Denk
2012-12-19 20:43 ` [U-Boot] [U-Boot, 1/2] spi: Add progress percentage and write speed to `sf update` Tom Rini
2012-12-19 20:46   ` Simon Glass
2012-12-19 20:59     ` Tom Rini
2012-12-19 22:59       ` Tom Rini
2012-12-19 23:14         ` Wolfgang Denk
2012-12-20  1:03           ` Tom Rini
2012-12-20  1:18             ` Simon Glass
2012-12-20 15:04               ` Tom Rini
2012-12-21  8:46               ` Jagan Teki
2012-12-21 18:21                 ` Simon Glass
2012-12-21 19:52                   ` Wolfgang Denk
2012-12-19 23:10 ` [U-Boot] [PATCH " Wolfgang Denk
2012-12-19 23:20   ` Simon Glass
2012-12-19 23:42     ` Scott Wood [this message]
2012-12-20  6:20       ` Wolfgang Denk

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=1355960533.12062.16@snotra \
    --to=scottwood@freescale.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.