public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben@fluff.org>
To: Vijay Kumar <vijaykumar@bravegnu.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Read/Busy as Interrupt
Date: Fri, 15 Jun 2007 10:46:33 +0100	[thread overview]
Message-ID: <20070615094633.GA3732@fluff.org.uk> (raw)
In-Reply-To: <15361.202.144.30.226.1181887978.squirrel@www.bravegnu.org>

On Fri, Jun 15, 2007 at 11:42:58AM +0530, Vijay Kumar wrote:
> Hi Everyone,
> we have a custom MPC8560 board with a Micron NAND flash (MT29F4G08AAA).
> The flash has the following specification with regards to the ready/busy
> pin.
> 
> Block Erase - Max: 2ms, Typical: 1.5ms
> Page Prog - Max: 600us, Typical: 220us

You will also need to take into account the rise time (capacitance of
the line, versus the pull-up resistance used). Typically, with a 10K
resistor on a resonably complex board, it can add another 200-300uS
to the time taken.
 
> The MPC8560 does not have a NAND flash controller, and the NAND flash is
> interfaced through the local bus controller (UPM).
> 
> In a 2.6 linux kernel, is it better to implement a polling mechanism for
> the ready/busy pin or is it better to use interrupt (sleep/wake)
> mechanism.
> 
> The block erase seems to be a good candidate for interrupt mechansim. But
> it is not very clear for the page prog operation. Please let us know your
> suggestions on this.

This may be worth looking at for other controllers. I know the
S3C2440 and later have the option for RnB change interrupt. Having
the wait for ready function being passed an indication of what command
it is waiting for may be a good idea.

I'd say for anything in the sub ms region, you may end up using a
quantity of time in the IRQ handling mechanisms.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

      reply	other threads:[~2007-06-15  9:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-15  6:12 Read/Busy as Interrupt Vijay Kumar
2007-06-15  9:46 ` Ben Dooks [this message]

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=20070615094633.GA3732@fluff.org.uk \
    --to=ben@fluff.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vijaykumar@bravegnu.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