JFFS2 NAND flash support

John Hall John.Hall at optionexist.co.uk
Tue Apr 2 09:56:12 EST 2002

On 28 March 2002 18:12 Thomas Gleixner <gleixner at autronix.de> wrote:

> > OK, I will take a look at the feasability of merging the two next
> > week after the holidays.

> I will check it in the next days too and will prepare the stuff,
> what's neccecary to support your hardware. This are only 3 things to
> do, IMHO
> 1. give the possibility to provide a hardware specific command write
> function
> 2. give the possibility to provide a hardware specific wait
> function,which can be interrupt driven, if the hardware has this
> feature.
> 3. rewrite the erase blocking
> Have a look in CVS after your Easter weekend. 


Have you made any progress on this? If not, then I am willing to start
making the changes myself. I've been looking through the code and
started to create a smartmedia hardware-specific file similar to spia.c.
A change that I need is a function in nand.c that fills in most of the
fields of the mtd, as an alternative to nand_scan. I have therefore
added a function nand_fillin_mtd that fills in the fields in the mtd
that are relevant to nand flash apart from those to do with its size.
nand_scan also calls this.

> > In your opinion, is the solution that I have chosen (an interrupt
> > handler which schedules a tasklet) the best one for handling erases?
> > It seems a little little untidy, because reads and writes are
> > handled differently since they are synchronous. I haven't done much
> > 2.4 development, so I'm still feeling my way.

> Yep, it's a nice feature at all. But we should keep the synchronous
> functions for read/write as the max. delay is less, than running
> through an interrupt handler.

You're right - the context switches would give too big an overhead.

John Hall

More information about the linux-mtd mailing list