From: Aras Vaichas <arasv@magellan-technology.com>
To: MTD-LIST <linux-mtd@lists.infradead.org>
Subject: Re: JFFS2+NAND problem in 2.6.13-at91
Date: Wed, 14 Sep 2005 14:20:08 +1000 [thread overview]
Message-ID: <4327A4F8.60300@magellan-technology.com> (raw)
In-Reply-To: <432691B7.5040804@magellan-technology.com>
Aras Vaichas wrote:
> Aras Vaichas wrote:
>
>>Hi,
>>
>>I was previously using 2.6.12-rc1, AT91 with JFFS2 on NAND and I had no
>>problems whatsoever with using JFFS2 on NAND.
>>
>>I recently upgraded to 2.6.13 and now JFFS2 on NAND seems a little broken ...
Jian Zhang wrote:
> i turn off debugging information( only MTD_DEBUG_LEVEL3) in nand_read_ecc( ),
> nand_write_ecc( ),nand_read_oob( ),nand_write_oob( ) which contained in
nand_base.c
> seperately. eventually,i found that it works well except turning off debugging
> info in nand_read_oob( ).so i insert 3us delay in this routine.
Thanks for the hint, I've got my NAND working again.
I did a diff between the nand_base.c version shipped with 2.6.13 (v1.147) and
2.6.12-rc1 (v1.138) and noticed that a delay loop had been moved further down
the code, I moved this delay back to where it was in v1.138 and it is now
working again. i assume that there was a probably a good reason to move this
delay in the first place though and I don't wish to break anything else ...
e.g.
--- drivers/mtd/nand/nand_base.c.orig 2005-09-14 13:28:07.000000000 +1000
+++ drivers/mtd/nand/nand_base.c 2005-09-14 13:37:59.000000000 +1000
@@ -1410,6 +1410,18 @@
this->read_buf(mtd, &buf[i], thislen);
i += thislen;
+
+ /* Apply delay or wait for ready/busy pin
+ * Do this before the AUTOINCR check, so no problems
+ * arise if a chip which does auto increment
+ * is marked as NOAUTOINCR by the board driver.
+ */
+ if (!this->dev_ready)
+ udelay (this->chip_delay);
+ else
+ nand_wait_ready(mtd);
+
+
/* Read more ? */
if (i < len) {
page++;
@@ -1421,16 +1433,6 @@
this->select_chip(mtd, -1);
this->select_chip(mtd, chipnr);
}
-
- /* Apply delay or wait for ready/busy pin
- * Do this before the AUTOINCR check, so no problems
- * arise if a chip which does auto increment
- * is marked as NOAUTOINCR by the board driver.
- */
- if (!this->dev_ready)
- udelay (this->chip_delay);
- else
- nand_wait_ready(mtd);
/* Check, if the chip supports auto page increment
* or if we have hit a block boundary.
Tom, did you want to check this? Should I submit a patch?
regards,
Aras Vaichas
next prev parent reply other threads:[~2005-09-14 4:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-13 6:28 JFFS2+NAND problem in 2.6.13-at91 Aras Vaichas
2005-09-13 8:45 ` Aras Vaichas
2005-09-14 4:20 ` Aras Vaichas [this message]
2005-09-14 13:05 ` Timofei V. Bondarenko
2005-09-14 12:34 ` Artem B. Bityuckiy
2005-09-15 1:46 ` Aras Vaichas
2005-09-15 7:30 ` Artem B. Bityuckiy
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=4327A4F8.60300@magellan-technology.com \
--to=arasv@magellan-technology.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.