public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pathompong Puengrostham <jay4mail@yahoo.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 on NAND, Magic bitmask 0x1985 not found
Date: Wed, 14 Jul 2004 12:39:56 +0200	[thread overview]
Message-ID: <1089801596.5255.73.camel@thomas.tec.linutronix.de> (raw)
In-Reply-To: <40F50325.3000404@yahoo.com>

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

On Wed, 2004-07-14 at 11:55, Pathompong Puengrostham wrote:

> The chip I'm using do autoincrement but I thought that after CE goes
> high I have to send the read command again which is not correct.
> Now I don't set NAND_NO_AUTOINCR and it works good. But I still need the
> delays.

Can you try this one ? It's against current CVS code.

tglx



[-- Attachment #2: nand_base.diff --]
[-- Type: text/x-patch, Size: 3240 bytes --]

? nand.diff
? nand_base.diff
Index: nand_base.c
===================================================================
RCS file: /home/cvs/mtd/drivers/mtd/nand/nand_base.c,v
retrieving revision 1.112
diff -u -r1.112 nand_base.c
--- nand_base.c	13 Jul 2004 08:28:21 -0000	1.112
+++ nand_base.c	14 Jul 2004 10:45:55 -0000
@@ -964,34 +964,34 @@
 		oobofs += mtd->oobsize - hweccbytes * eccsteps;
 		page++;
 		numpages--;
-		if (!numpages)
-			break;
-		
+
 		/* 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.
+		 * Do this also before returning, so the chip is
+		 * ready for the next command.
 		*/
 		if (!this->dev_ready) 
 			udelay (this->chip_delay);
 		else
 			while (!this->dev_ready(mtd));	
+
+		/* All done, return happy */
+		if (!numpages)
+			return 0;
+		
 			
 		/* Check, if the chip supports auto page increment */ 
 		if (!NAND_CANAUTOINCR(this))
 			this->cmdfunc (mtd, NAND_CMD_READ0, 0x00, page);
 	}
-	res = 0;
 	/* 
-	 * Terminate the read command. This is faster than sending a reset command or 
-	 * applying a 20us delay before issuing the next programm sequence.
-	 * This is not a problem for all chips, but I have found a bunch of them.
-	 * FIXME, CHECKME: Does this work on systems, where CE is not driven
-	 * by an GPIO pin ?
+	 * Terminate the read command. We come here in case of an error
+	 * So we must issue a reset command.
 	 */
 out:	 
-	this->select_chip(mtd, -1);
-	this->select_chip(mtd, chipnr);
+	this->cmdfunc (mtd, NAND_CMD_RESET, -1, -1);
 	return res;
 }
 #endif
@@ -1248,14 +1248,6 @@
 		} else		
 			read += mtd->oobblock;
 
-		if (read == len)
-			break;	
-
-		/* For subsequent reads align to page boundary. */
-		col = 0;
-		/* Increment page address */
-		realpage++;
-
 		/* 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
@@ -1266,6 +1258,14 @@
 		else
 			while (!this->dev_ready(mtd));	
 			
+		if (read == len)
+			break;	
+
+		/* For subsequent reads align to page boundary. */
+		col = 0;
+		/* Increment page address */
+		realpage++;
+
 		page = realpage & this->pagemask;
 		/* Check, if we cross a chip boundary */
 		if (!page) {
@@ -1345,19 +1345,21 @@
 		thislen = min_t(int, thislen, len);
 		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
+			while (!this->dev_ready(mtd));	
+
 		/* Read more ? */
 		if (i < len) {
 			page++;
 			col = 0;
-			/* 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
-				while (!this->dev_ready(mtd));	
 
 			/* Check, if we cross a chip boundary */
 			if (!(page & this->pagemask)) {

      reply	other threads:[~2004-07-14 10:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-14  4:09 JFFS2 on NAND, Magic bitmask 0x1985 not found Pathompong Puengrostham
2004-07-14  4:57 ` Pathompong Puengrostham
2004-07-14  7:41   ` Thomas Gleixner
2004-07-14  9:55     ` Pathompong Puengrostham
2004-07-14 10:39       ` Thomas Gleixner [this message]

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=1089801596.5255.73.camel@thomas.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=jay4mail@yahoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox