public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Jared Hulbert <jaredeh@gmail.com>
To: llandre <r&d2@dave-tech.it>
Cc: linux-mtd@lists.infradead.org
Subject: Re: How to exploit STS pin of Strata Flash
Date: Wed, 29 Dec 2004 20:23:18 -0800	[thread overview]
Message-ID: <6934efce041229202370761a59@mail.gmail.com> (raw)
In-Reply-To: <6.0.1.1.0.20041229093407.01f20e88@192.168.2.1>

> when I helped Thomas Gleixner to debug the code to support 2k-page NAND
> devices, I
> discussed with him about this subject. For NAND chips there are three
> possibilities:
> 1) if the driver can not read the ready/busy pin, MTD waits the maximum
> delay required
> by the device to perform such operations (this clearly reduces performance)
> 2) if the driver can read the ready/busy pin, MTD polls this pin in order to
> detect the end of operation (no accesses on the bus)
> 3) if the ready/busy ping is connected to an IRQ line, the driver can
> "sleep" until
> the processor receives an interrupt from the NAND (I never implemented this
> solution so far)

My biggest concern is this STS pin is not something supported on many
strataflash chips.   Though this might be an elegant solution for a
system with irq lines to spare using these particular chips I don't
think it would be used often enough to be supportable.

> I don't know how NOR/Strata Flash drivers work and I thouhgt they implement
> the well-known data polling algorithm to detect the end of operation.
> However, if they actually "sleeps" as you pointed out, I
> clearly am wrong. If I'm right instead, the data-polling algorithm wastes
> bandwidth
> because it performs a lot of read accesses just to read the value of a bit.

in 2.6.10 drivers/mtd/chips/
cfi_cmdset_0001.c:1065  sleeps for the word write if I understand
cfi_udelay() correctly
cfi_cmdset_0001.c:1308  sleeps for the buffered write if I understand
cfi_udelay() correctly
cfi_cmdset_0001.c:1470  sleeps for the erase

> This can lead to problems for example when you have a bus-demanding
> peripheral such
> as a LCD controller. In this case the wasted bandwith can lead to flickering.
> In conclusion, to avoid data-polling algorithm, it is possible to implement the
> same ready/busy pin strategy used for NAND chips.

I can imagine that happens, but does it?  I'm never been able to see
that kind of effect, have you?  Maybe the sleeps work good enough.  If
this sort of thing happens and we can prove it... well maybe we can
influence the chipheads who design this stuff.

,Jared

  reply	other threads:[~2004-12-30  4:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-27 11:23 How to exploit STS pin of Strata Flash llandre
2004-12-27 17:46 ` Jared Hulbert
2004-12-28  8:56   ` llandre
2004-12-28 17:44     ` Jared Hulbert
2004-12-29  9:00       ` llandre
2004-12-30  4:23         ` Jared Hulbert [this message]
2004-12-30  9:46           ` llandre
2004-12-30 22:52             ` Jared Hulbert
2005-01-03 10:00               ` llandre

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=6934efce041229202370761a59@mail.gmail.com \
    --to=jaredeh@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=r&d2@dave-tech.it \
    /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