Read/Busy as Interrupt

Read/Busy as Interrupt

[Vijay Kumar]

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

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.

Please let me know if further details are required.

Thanks in advance.

Regards,
Vijay

Re: Read/Busy as Interrupt

[Ben Dooks]

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'