JFFS2 NAND flash support
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
> 2. give the possibility to provide a hardware specific wait
> function,which can be interrupt driven, if the hardware has this
> 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.
More information about the linux-mtd