Read/nBusy via interrupt

[Thomas Gleixner]

On Fri, 2004-10-29 at 09:43 +1000, Aras Vaichas wrote:
> Ben Dooks wrote:
> > Does anyone here have any comments over the pros/cons of using
> > an interrupt which goes off to wait for a NAND flash ready/not-busy
> > signal?
> > 
> 
> pros of using interrupt:
> * faster MTD access (maybe, depends on polling rate) but as a percentage of 
> total access time it probably doesn't make much difference.

For program and erase it makes a lot of difference. The waiting process
releases the CPU and gets woken when the job is done. Arguing with
percentage of total access time is utter crap here. The poll/yield loop
involves unneccecary context switches, which can significantly influence
the overall system performance on smaller systems.

> * less cpu overhead
> 
> cons of using interrupt:
> * more pins used up on CPU

No. Usually R/B is connected anyway.

> * more code to write and debug!

About 20 lines. I'm scared.

> * more interrupts going off in system

They go only off, when a long lasting operation is in progress

> * more pins needed on MTD -> more expensive boards and chips, longer board 
> design times

He ? NAND FLASH has a ready/busy pin, which does not produce extra
costs. What's the longer design time per pin on complex boards ?
A typical 32bit embedded system CPU board uses alone about 500 pins for
connecting CPU, SDRAM, power and the on chip peripherals. Do you really
want to tell me, that 1 more pin will increase board costs and design
time significantly ?

> If you take a look at the 8-CASON part, you'll notice that in order to reduce 
> pin count, they leave out the ready/nbusy signal because this information can 
> be obtained by polling. This is really a matter of board space as you can fit 
> 1Megabyte of bootable FLASH into a surface mount 8pin package by leaving out 
> this pin.

This is a 1 MByte boot FLASH designed for space constraint devices. You
need a CPU which can boot from those. 

We are talking about NAND >= 32MB, which is often used for filesystems.

> If you wanted to improve performance, you would simply find out how long the 
> MTD usually stays busy for and only resume polling after that time.

Nice plan. Using what ? Typical erase/program time, maximum
erase/program time ? And waiting in the worst case 10ms for something
what takes 3ms ? This improves performance a lot.

> If you can spare the board space, why not use interrupts? Make it a kernel 
> option. MTD_EADYNBUSY_INTERRUPT ?

There's no option neccecary at all. This is board related and has to be
solved by the board driver anyway. The functionality to do so is already
there.

tglx