public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Schleef <ds@schleef.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: mtd@infradead.org
Subject: Re: sharp driver dissimilarities
Date: Sat, 28 Apr 2001 10:15:55 -0700	[thread overview]
Message-ID: <20010428101555.A22768@stm.lbl.gov> (raw)
In-Reply-To: <17699.988474317@redhat.com>; from dwmw2@infradead.org on Sat, Apr 28, 2001 at 05:11:57PM +0100

On Sat, Apr 28, 2001 at 05:11:57PM +0100, David Woodhouse wrote:
> 
> ds@schleef.org said:
> >  I tried and failed, but that may be just my lack of understanding of
> > the CFI driver.  The commands, command write locations, and status
> > bits have no similarity to other chip drivers.
> 
> The commands certainly have some similarity with the cfi_cmdset_0001 code, 
> which isn't particularly surprising as command set 0001 is 'Intel/Sharp'.

Heh...

> However, at the time you did sharp.c, I believe that CFI code wasn't 
> sufficiently generic to deal with 4x8-bit chips. It ought to manage that 
> now, though.

I'm not sure that was the case.  I'd chalk it up to be not being
very observant.

I actually started from the cfi_cmdset_0001.c driver.  In the
process, I noticed a few things that I don't like about it.

The write process uses word_write_time and adjusts it so that it
settles at the average write time.  The problem with that
method is that half the time, you will be sleeping for 10 ms
on something that may finish in 1 more usec of waiting.  Not
pretty.  The sharp driver write speed went up by a factor of
about 10 when I fixed that.  It just uses the braindead "spin
on the status register" for ~100 us.  Perhaps some kind of
hybrid is better, but schedule_timeout is a significant
performance hit.

A similar thing is true about block erase -- the schedule_timeout(HZ)
means that the earliest time the driver will notice that the
chip is done erasing is 1 s.

I also didn't understand how the locking was supposed to work,
so I rewrote it in the sharp driver.  I like it better.

On the other hand, of course, the sharp driver only handles
one interleve.





dave...



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

  reply	other threads:[~2001-04-28 17:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-26 15:55 Power blackouts and brownouts Vipin Malik
2001-04-27  7:39 ` Joakim Tjernlund
2001-04-27 14:30   ` Vipin Malik
2001-04-27 14:34     ` David Woodhouse
2001-04-27 15:31       ` Vipin Malik
2001-04-27 20:37       ` David Schleef
2001-04-28 10:34         ` David Woodhouse
2001-04-28 16:00           ` sharp driver dissimilarities David Schleef
2001-04-28 16:11             ` David Woodhouse
2001-04-28 17:15               ` David Schleef [this message]
2001-04-28 17:26                 ` David Woodhouse

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=20010428101555.A22768@stm.lbl.gov \
    --to=ds@schleef.org \
    --cc=dwmw2@infradead.org \
    --cc=mtd@infradead.org \
    /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