public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <gleixner@autronix.de>
To: "John Hall" <John.Hall@optionexist.co.uk>,
	<linux-mtd@lists.infradead.org>
Subject: Re: JFFS2 NAND flash support
Date: Wed, 27 Mar 2002 19:16:27 +0100	[thread overview]
Message-ID: <200203271816.g2RIGSB30367@thomas.tec.autronix.de> (raw)
In-Reply-To: <541025071C7AC24C84E9F82296BB9B950804C4@OPTEX1.optex.local>

On Wednesday, 27. March 2002 18:42, John Hall wrote:
> I'm wanting to get JFFS2 to go on some NAND flash (it's actually
> Smartmedia, but it's pretty much just NAND flash) with a 2.4.17 kernel.
It is exactly NAND flash, molded in thin plastic

> I've adapted the NAND flash driver in the kernel tree and that now seems
> to work for me.
maybe you have done duplicated work . See below.

> The jffs2 stuff in my kernel sources doesn't seem very up to date so
> I've got the latest CVS stuff. Which branch of cvs do I need to use?
> Should I update the whole of the mtd subsystem or can I just use the
> updated jffs2 stuff?
The current developer branch. Take care there were a lot of changes in nand.c 
and hardware driver files. See nand.c / autcpu12.c
Adaptions should made in hardware drivers like autcpu12 and not in nand.c
If there's a neccecarity to do this, please contact me or David Woodhouse.

> I also came across some problems with the existing NAND flash driver,
> especially with erases. It doesn't seem to mark an erase as done,
>   i.e. instr->state = MTD_ERASE_DONE;
It's fixed in CVS long ago

> Also, when doing an erase it obtains a spin lock that disables all
> bottom halves from running. It holds this lock for the duration of the
> erase, which is up to 4ms in the code - is this really a good idea? The
> Smartmedia specs say that this delay can be up to 400ms! Definitely not
> a good idea.
There's no better to ensure, that erase read and write can coexist at the 
moment. But you're invited to hack a better solution :)

I this a new card type ? All chips and card types I know, have maximum block 
erase times of 20ms.

-- 
Thomas
_________________________________
Thomas Gleixner <gleixner@autronix.de>
autronix automation http://www.autronix.de

  reply	other threads:[~2002-03-27 18:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-27 17:42 JFFS2 NAND flash support John Hall
2002-03-27 18:16 ` Thomas Gleixner [this message]
2002-03-27 18:26   ` David Woodhouse
2002-03-27 19:10     ` Thomas Gleixner
  -- strict thread matches above, loose matches on Subject: below --
2002-03-28  9:41 John Hall
2002-03-28 10:00 ` Thomas Gleixner
2002-03-28 10:01   ` David Woodhouse
2002-03-28 17:23 John Hall
2002-03-28 17:18 ` David Woodhouse
     [not found] <541025071C7AC24C84E9F82296BB9B950804CD@OPTEX1.optex.local>
2002-03-28 18:12 ` Thomas Gleixner
2002-04-02 14:56 John Hall

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=200203271816.g2RIGSB30367@thomas.tec.autronix.de \
    --to=gleixner@autronix.de \
    --cc=John.Hall@optionexist.co.uk \
    --cc=linux-mtd@lists.infradead.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