New release of MTD code pending.

New release of MTD code pending.

[David Woodhouse]

I'm intending to make a new release some time this week.

I'd like to ship a tarball which holds drivers/mtd, along with two patches 
which add that directory to the kernel infrastructure.

I can't run 2.2 easily on my current testbed, so I would appreciate it if 
someone could give me a patch which adds _only_ the Makefile, arch/*/config.in 
and init code to the 2.2 kernel.

I'm going to update the FTL code so it compiles with 2.3 kernels - probably by 
taking David Hinds' latest version from the PCMCIA code and porting it to MTD 
again, so I get the last 3 years' worth of bug fixes while I'm at it.

The mtdblock driver needs fixing too - volunteers?

We're now in the interesting position of having two flash filesystems present 
in the tree - one of which (FFS2) compiles only on 2.2 kernels, and the other 
of which (JFFS) only compiles on 2.3. It'd be nice to fix that at some point.


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[Alexander Larsson]

On Mon, 27 Mar 2000, David Woodhouse wrote:

> I'm intending to make a new release some time this week.
 Cool.
 
> I'm going to update the FTL code so it compiles with 2.3 kernels - probably by 
> taking David Hinds' latest version from the PCMCIA code and porting it to MTD 
> again, so I get the last 3 years' worth of bug fixes while I'm at it.
> 
> The mtdblock driver needs fixing too - volunteers?
> 
> We're now in the interesting position of having two flash filesystems present 
> in the tree - one of which (FFS2) compiles only on 2.2 kernels, and the other 
> of which (JFFS) only compiles on 2.3. It'd be nice to fix that at some point.

I saw the new FTL code uses 2.3 style module initialization, and so does
my mtdram code. Are we targeting only 2.3, or should we add some kludges
to support older versions?

I'm mostly interested in 2.4 (and 2.5) stuff, as I hope we can get MTD
included in the 2.5 release cycle. Also much of the API (i.e. modules) is
cleaner in 2.3.

/ Alex




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[David Woodhouse]

alex@cendio.se said:
>  I saw the new FTL code uses 2.3 style module initialization, and so
> does my mtdram code. Are we targeting only 2.3, or should we add some
> kludges to support older versions?

I'd like to support 2.2 unless it's too much trouble. doc2000 and nftl already 
do (should?)

> I'm mostly interested in 2.4 (and 2.5) stuff, as I hope we can get MTD
> included in the 2.5 release cycle. Also much of the API (i.e. modules)
> is cleaner in 2.3. 

I hope we can get it in earlier than 2.5. "New drivers that don't affect 
infrastructure are never too late."


--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[Alexander Larsson]

On Mon, 27 Mar 2000, David Woodhouse wrote:

> I hope we can get it in earlier than 2.5. "New drivers that don't affect 
> infrastructure are never too late."

Sure, but there are some architecture changes that should be done before
that. (The ones we discussed last week).

/ Alex




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[David Woodhouse]

alex@cendio.se said:
>  Sure, but there are some architecture changes that should be done
> before that. (The ones we discussed last week). 

Definitely. I'm going through the FTL code first - to remind myself of how it 
actually works. Then I'll get round to making the changes we talked about.

As it is, I haven't actually looked at some of this code in three years. For 
example, I had no clue how the async erases worked until I just reread it.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[Alexander Larsson]

On Mon, 27 Mar 2000, David Woodhouse wrote:

> alex@cendio.se said:
> >  Sure, but there are some architecture changes that should be done
> > before that. (The ones we discussed last week). 
> 
> Definitely. I'm going through the FTL code first - to remind myself of how it 
> actually works. Then I'll get round to making the changes we talked about.
> 
> As it is, I haven't actually looked at some of this code in three years. For 
> example, I had no clue how the async erases worked until I just reread it.

I've got some questions on the async erase btw:

When I fire away a flash erase, can i just continue working with the
flash, content with knowing that if i do a read or write while the chip is
erasing it will block? I thought so at first, and it would be the logical
thing. 

Some code in the current drivers made me doubt this though, so i added an
explicit sleep until i got the finished callback.

The code in question is stuff like: 
doc100.c: flashcard_read():
 /* There is an erase in progress or pending for this device. Stop it */
 timeron = del_timer(&flashcard_timer);
                
 if (priv->cur_erases && priv->cur_erases->cell == cell) 
 {
   /* The erase is on the current cell. Just return all 0xff */ 
   add_timer(&flashcard_timer);
                        
   printk("Cell %d currently erasing. Setting to all 0xff\n",cell);
   memset(buf, 0xff, *retlen);
   return 0;

WTF is this?

Also, doc2000.c: doc_erase() doesn't seem to call the callback function at
all.

/ Alex








To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[David Woodhouse]

alex@cendio.se said:
>  When I fire away a flash erase, can i just continue working with the
> flash, content with knowing that if i do a read or write while the
> chip is erasing it will block? I thought so at first, and it would be
> the logical thing.  

This is how it _should_ work. The hardware driver should keep track of when 
each chip is busy erasing, and when it receives a new request for that chip, 
it may block, or may decide to interrupt the erase (it must then restart the 
erase itself).


>  WTF is this? 

Broken. Luckily, not even M-Systems can find examples of the device that code
is supposed to drive. I _think_ that the idea was "if we're currently erasing 
this cell, then it's going to be all 0xFF, so there's no point in waiting 
until it's done, we might as well use memset."


>  Also, doc2000.c: doc_erase() doesn't seem to call the callback
> function at all.

Two reasons: firstly, like I said - I didn't remember how it worked, so I just
implemented doc_erase() synchronously. nftl.c relies on that, so would break if
you coded a new NAND device driver which wasn't synchronous (Patent issues
aside).

Secondly, it was easier to get something up and running without worrying about
threading - I've been putting off the threading of doc2000 / nftl until I'm
happy with the correctness of the NFTL code. But it's definitely on the TODO
list.




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[Trevor Woolven]

David Woodhouse wrote:
> 
> alex@cendio.se said:
> >  I saw the new FTL code uses 2.3 style module initialization, and so
> > does my mtdram code. Are we targeting only 2.3, or should we add some
> > kludges to support older versions?
> 
> I'd like to support 2.2 unless it's too much trouble. doc2000 and nftl already
> do (should?)
> 
> > I'm mostly interested in 2.4 (and 2.5) stuff, as I hope we can get MTD
> > included in the 2.5 release cycle. Also much of the API (i.e. modules)
> > is cleaner in 2.3.
> 
> I hope we can get it in earlier than 2.5. "New drivers that don't affect
> infrastructure are never too late."
> 
> --
> dwmw2
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org
I definitely need 2.2 support as I'm very close to a customer delivery
and don't need any other hassles at this moment in time. Thanks.

Just my 4d worth

Trev.
-- 
Trevor Woolven - Director of Customer Applications Engineering
Zentropix Inc - a Lineo company

Tel: +44 (0)1273 234 647	 Fax: +44 (0)1273 704 482

Visit http://www.zentropix.com/ for Real Time Linux Tools
Visit http://www.realtimelinux.org/ for Real Time Linux Information


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: New release of MTD code pending.

[David Woodhouse]

alex@cendio.se said:
>  All this should really be documented in mtd.h, so that one can rely
> on certain properties. The you can just fix drivers that don't
> implement stuff you depend on, instead of having to read all drivers
> to see how the api really works.

Definitely. At the moment, I don't think there even _is_ a good example to
point at. 

I started this in HTML at one point, but didn't get very far, do didn't ever 
publish it:
	http://www.linux-mtd.infradead.org/tech/API.html

> I was thinking of using alan's new kernel documentation stuff. That
> would be nice.

Yes, the DocBook stuff looks quite good.

I'd very much like to get some real documentation done, then go through the 
existing drivers and audit them sensibly against that documentation. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org