linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR
@ 2011-11-24  0:41 b35362
  2011-11-24  0:41 ` [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write b35362
  2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
  0 siblings, 2 replies; 14+ messages in thread
From: b35362 @ 2011-11-24  0:41 UTC (permalink / raw)
  To: dwmw2, Artem.Bityutskiy, scottwood
  Cc: linuxppc-dev, akpm, linux-mtd, linux-kernel

From: Liu Shuo <b35362@freescale.com>

On both of large-page chip and small-page chip, we always should use
'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
use a overflowed 'column' to set it.

Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index cc08a11..6fce7da 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -414,9 +414,17 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		         page_addr, column);
 
 		elbc_fcm_ctrl->column = column;
-		elbc_fcm_ctrl->oob = 0;
 		elbc_fcm_ctrl->use_mdr = 1;
 
+		if (column >= mtd->writesize) {
+			/* OOB area */
+			column -= mtd->writesize;
+			elbc_fcm_ctrl->oob = 1;
+		} else {
+			WARN_ON(column != 0);
+			elbc_fcm_ctrl->oob = 0;
+		}
+
 		fcr = (NAND_CMD_STATUS   << FCR_CMD1_SHIFT) |
 		      (NAND_CMD_SEQIN    << FCR_CMD2_SHIFT) |
 		      (NAND_CMD_PAGEPROG << FCR_CMD3_SHIFT);
@@ -441,16 +449,12 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 			         (FIR_OP_CW1 << FIR_OP6_SHIFT) |
 			         (FIR_OP_RS  << FIR_OP7_SHIFT));
 
-			if (column >= mtd->writesize) {
+			if (elbc_fcm_ctrl->oob)
 				/* OOB area --> READOOB */
-				column -= mtd->writesize;
 				fcr |= NAND_CMD_READOOB << FCR_CMD0_SHIFT;
-				elbc_fcm_ctrl->oob = 1;
-			} else {
-				WARN_ON(column != 0);
+			else
 				/* First 256 bytes --> READ0 */
 				fcr |= NAND_CMD_READ0 << FCR_CMD0_SHIFT;
-			}
 		}
 
 		out_be32(&lbc->fcr, fcr);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write
  2011-11-24  0:41 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR b35362
@ 2011-11-24  0:41 ` b35362
  2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
  1 sibling, 0 replies; 14+ messages in thread
From: b35362 @ 2011-11-24  0:41 UTC (permalink / raw)
  To: dwmw2, Artem.Bityutskiy, scottwood
  Cc: linuxppc-dev, akpm, linux-mtd, linux-kernel

From: Liu Shuo <b35362@freescale.com>

When we do a non-full-page write, the length be set to FBCR should
not be 'elbc_fcm_ctrl->index', it should be 'elbc_fcm_ctrl->index -
elbc_fcm_ctrl->column'.

Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 6fce7da..d634c5f 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -474,7 +474,8 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		 */
 		if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
 		    elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
-			out_be32(&lbc->fbcr, elbc_fcm_ctrl->index);
+			out_be32(&lbc->fbcr,
+				elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
 		else
 			out_be32(&lbc->fbcr, 0);
 
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  0:41 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR b35362
  2011-11-24  0:41 ` [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write b35362
@ 2011-11-24  0:41 ` b35362
  2011-11-24  7:37   ` Li Yang-R58472
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: b35362 @ 2011-11-24  0:41 UTC (permalink / raw)
  To: dwmw2, Artem.Bityutskiy, scottwood
  Cc: linuxppc-dev, akpm, linux-mtd, linux-kernel

From: Liu Shuo <b35362@freescale.com>

Freescale FCM controller has a 2K size limitation of buffer RAM. In order
to support the Nand flash chip whose page size is larger than 2K bytes,
we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
them to a large buffer.

Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |  211 +++++++++++++++++++++++++++++++++++---
 1 files changed, 194 insertions(+), 17 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index d634c5f..c96e714 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -55,7 +55,9 @@ struct fsl_elbc_mtd {
 	struct device *dev;
 	int bank;               /* Chip select bank number           */
 	u8 __iomem *vbase;      /* Chip select base virtual address  */
-	int page_size;          /* NAND page size (0=512, 1=2048)    */
+	int page_size;          /* NAND page size, the mutiple of 2048.
+				 * (0=512, 1=2048, 2=4096, 4=8192....)
+				 */
 	unsigned int fmr;       /* FCM Flash Mode Register value     */
 };
 
@@ -75,6 +77,8 @@ struct fsl_elbc_fcm_ctrl {
 	unsigned int use_mdr;    /* Non zero if the MDR is to be set      */
 	unsigned int oob;        /* Non zero if operating on OOB data     */
 	unsigned int counter;	 /* counter for the initializations	  */
+
+	char *buffer;            /* just be used when pagesize > 2048     */
 };
 
 /* These map to the positions used by the FCM hardware ECC generator */
@@ -150,6 +154,42 @@ static struct nand_bbt_descr bbt_mirror_descr = {
 };
 
 /*=================================*/
+static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
+	void *src, *dst;
+	int len = (oob ? 64 : 2048);
+
+	if (oob)
+		dst = elbc_fcm_ctrl->buffer + mtd->writesize + subpage * 64;
+	else
+		dst = elbc_fcm_ctrl->buffer + subpage * 2048;
+
+	src = elbc_fcm_ctrl->addr + (oob ? 2048 : 0);
+	memcpy_fromio(dst, src, len);
+}
+
+static void buffer_to_io(struct mtd_info *mtd, int subpage, int oob)
+{
+	struct nand_chip *chip = mtd->priv;
+	struct fsl_elbc_mtd *priv = chip->priv;
+	struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
+	void *src, *dst;
+	int len = (oob ? 64 : 2048);
+
+	if (oob)
+		src = elbc_fcm_ctrl->buffer + mtd->writesize + subpage * 64;
+	else
+		src = elbc_fcm_ctrl->buffer + subpage * 2048;
+
+	dst = elbc_fcm_ctrl->addr + (oob ? 2048 : 0);
+	memcpy_toio(dst, src, len);
+
+	/* See the in_8() in fsl_elbc_write_buf() */
+	in_8(elbc_fcm_ctrl->addr);
+}
 
 /*
  * Set up the FCM hardware block and page address fields, and the fcm
@@ -193,7 +233,7 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob)
 
 	/* for OOB data point to the second half of the buffer */
 	if (oob)
-		elbc_fcm_ctrl->index += priv->page_size ? 2048 : 512;
+		elbc_fcm_ctrl->index += mtd->writesize;
 
 	dev_vdbg(priv->dev, "set_addr: bank=%d, "
 			    "elbc_fcm_ctrl->addr=0x%p (0x%p), "
@@ -311,6 +351,7 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 	struct fsl_lbc_ctrl *ctrl = priv->ctrl;
 	struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = ctrl->nand;
 	struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+	int i;
 
 	elbc_fcm_ctrl->use_mdr = 0;
 
@@ -339,6 +380,26 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 
 		fsl_elbc_do_read(chip, 0);
 		fsl_elbc_run_command(mtd);
+
+		if (priv->page_size <= 1)
+			return;
+
+		/* Continue to read the rest bytes if writesize > 2048 */
+		io_to_buffer(mtd, 0, 0);
+		io_to_buffer(mtd, 0, 1);
+
+		out_be32(&lbc->fir, FIR_OP_RB << FIR_OP1_SHIFT);
+
+		for (i = 1; i < priv->page_size; i++) {
+			/*
+			 * Maybe there are some reasons of FCM hardware timing,
+			 * we must insert a FIR_OP_NOP(0x00) before FIR_OP_RB.
+			 */
+			fsl_elbc_run_command(mtd);
+			io_to_buffer(mtd, i, 0);
+			io_to_buffer(mtd, i, 1);
+		}
+
 		return;
 
 	/* READOOB reads only the OOB because no ECC is performed. */
@@ -347,13 +408,36 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		         "fsl_elbc_cmdfunc: NAND_CMD_READOOB, page_addr:"
 			 " 0x%x, column: 0x%x.\n", page_addr, column);
 
-		out_be32(&lbc->fbcr, mtd->oobsize - column);
-		set_addr(mtd, column, page_addr, 1);
+		if (priv->page_size <= 1) {
+			out_be32(&lbc->fbcr, mtd->oobsize - column);
+			set_addr(mtd, column, page_addr, 1);
+		} else {
+			out_be32(&lbc->fbcr, 64);
+			set_addr(mtd, 0, page_addr, 1);
+			elbc_fcm_ctrl->index += column;
+		}
 
 		elbc_fcm_ctrl->read_bytes = mtd->writesize + mtd->oobsize;
 
 		fsl_elbc_do_read(chip, 1);
 		fsl_elbc_run_command(mtd);
+
+		if (priv->page_size <= 1)
+			return;
+
+		if (column < 64)
+			io_to_buffer(mtd, 0, 1);
+
+		out_be32(&lbc->fbcr, 2112);
+		out_be32(&lbc->fir, FIR_OP_RB << FIR_OP1_SHIFT);
+		out_be32(&lbc->fpar, in_be32(&lbc->fpar) & ~FPAR_LP_MS);
+
+		for (i = 1; i < priv->page_size; i++) {
+			fsl_elbc_run_command(mtd);
+			if (column < (64 * (i + 1)))
+				io_to_buffer(mtd, i, 1);
+		}
+
 		return;
 
 	/* READID must read all 5 possible bytes while CEB is active */
@@ -429,7 +513,14 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		      (NAND_CMD_SEQIN    << FCR_CMD2_SHIFT) |
 		      (NAND_CMD_PAGEPROG << FCR_CMD3_SHIFT);
 
-		if (priv->page_size) {
+		if (priv->page_size > 1) {
+			/* writesize > 2048 */
+			out_be32(&lbc->fir,
+				 (FIR_OP_CM2 << FIR_OP0_SHIFT) |
+				 (FIR_OP_CA  << FIR_OP1_SHIFT) |
+				 (FIR_OP_PA  << FIR_OP2_SHIFT) |
+				 (FIR_OP_WB  << FIR_OP3_SHIFT));
+		} else if (priv->page_size) {
 			out_be32(&lbc->fir,
 			         (FIR_OP_CM2 << FIR_OP0_SHIFT) |
 			         (FIR_OP_CA  << FIR_OP1_SHIFT) |
@@ -458,7 +549,13 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		}
 
 		out_be32(&lbc->fcr, fcr);
-		set_addr(mtd, column, page_addr, elbc_fcm_ctrl->oob);
+		if (elbc_fcm_ctrl->oob && priv->page_size > 1) {
+			set_addr(mtd, 0, page_addr, 0);
+			elbc_fcm_ctrl->index = elbc_fcm_ctrl->column;
+		} else {
+			set_addr(mtd, column, page_addr, elbc_fcm_ctrl->oob);
+		}
+
 		return;
 	}
 
@@ -472,14 +569,59 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		 * then set the exact length, otherwise use a full page
 		 * write so the HW generates the ECC.
 		 */
-		if (elbc_fcm_ctrl->oob || elbc_fcm_ctrl->column != 0 ||
-		    elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize)
+		if (elbc_fcm_ctrl->oob) {
+			int len;
+			/* write oob */
+			if (priv->page_size > 1) {
+				/* when pagesize of chip is greater than 2048,
+				 * we have to write full page to write spare
+				 * region, so we fill '0xff' to main region
+				 * and some bytes of spare region which we
+				 * don't want to rewrite.
+				 * (write '1' won't change the original value)
+				 */
+				memset(elbc_fcm_ctrl->buffer, 0xff,
+						elbc_fcm_ctrl->column);
+				len = 2112;
+			} else {
+				len = elbc_fcm_ctrl->index -
+						elbc_fcm_ctrl->column;
+			}
+			out_be32(&lbc->fbcr, len);
+		} else if (elbc_fcm_ctrl->column != 0 ||
+		    elbc_fcm_ctrl->index != mtd->writesize + mtd->oobsize) {
 			out_be32(&lbc->fbcr,
 				elbc_fcm_ctrl->index - elbc_fcm_ctrl->column);
-		else
+		} else {
 			out_be32(&lbc->fbcr, 0);
+		}
+
+		if (priv->page_size > 1) {
+			buffer_to_io(mtd, 0, 0);
+			buffer_to_io(mtd, 0, 1);
+		}
 
 		fsl_elbc_run_command(mtd);
+
+		if (priv->page_size <= 1)
+			return;
+
+		out_be32(&lbc->fir, FIR_OP_WB << FIR_OP1_SHIFT);
+		for (i = 1; i < priv->page_size; i++) {
+			elbc_fcm_ctrl->use_mdr = 1;
+			/* For the last subpage */
+			if (i == priv->page_size - 1)
+				out_be32(&lbc->fir,
+					(FIR_OP_WB  << FIR_OP1_SHIFT) |
+					(FIR_OP_CM3 << FIR_OP2_SHIFT) |
+					(FIR_OP_CW1 << FIR_OP3_SHIFT) |
+					(FIR_OP_RS  << FIR_OP4_SHIFT));
+
+			buffer_to_io(mtd, i, 0);
+			buffer_to_io(mtd, i, 1);
+			fsl_elbc_run_command(mtd);
+		}
+
 		return;
 	}
 
@@ -548,7 +690,14 @@ static void fsl_elbc_write_buf(struct mtd_info *mtd, const u8 *buf, int len)
 		len = bufsize - elbc_fcm_ctrl->index;
 	}
 
-	memcpy_toio(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], buf, len);
+	if (mtd->writesize > 2048) {
+		memcpy(&elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index],
+				buf, len);
+	} else {
+		memcpy_toio(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index],
+				buf, len);
+	}
+
 	/*
 	 * This is workaround for the weird elbc hangs during nand write,
 	 * Scott Wood says: "...perhaps difference in how long it takes a
@@ -594,7 +743,13 @@ static void fsl_elbc_read_buf(struct mtd_info *mtd, u8 *buf, int len)
 
 	avail = min((unsigned int)len,
 			elbc_fcm_ctrl->read_bytes - elbc_fcm_ctrl->index);
-	memcpy_fromio(buf, &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index], avail);
+	if (mtd->writesize > 2048) {
+		memcpy(buf, &elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index],
+				avail);
+	} else {
+		memcpy_fromio(buf, &elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index],
+				avail);
+	}
 	elbc_fcm_ctrl->index += avail;
 
 	if (len > avail)
@@ -630,10 +785,17 @@ static int fsl_elbc_verify_buf(struct mtd_info *mtd, const u_char *buf, int len)
 		return -EINVAL;
 	}
 
-	for (i = 0; i < len; i++)
-		if (in_8(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index + i])
-				!= buf[i])
-			break;
+	if (mtd->writesize > 2048) {
+		for (i = 0; i < len; i++)
+			if (elbc_fcm_ctrl->buffer[elbc_fcm_ctrl->index + i]
+					!= buf[i])
+				break;
+	} else {
+		for (i = 0; i < len; i++)
+			if (in_8(&elbc_fcm_ctrl->addr[elbc_fcm_ctrl->index + i])
+					!= buf[i])
+				break;
+	}
 
 	elbc_fcm_ctrl->index += len;
 	return i == len && elbc_fcm_ctrl->status == LTESR_CC ? 0 : -EIO;
@@ -716,8 +878,9 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 	if (mtd->writesize == 512) {
 		priv->page_size = 0;
 		clrbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
-	} else if (mtd->writesize == 2048) {
-		priv->page_size = 1;
+	} else if (mtd->writesize >= 2048 && mtd->writesize <= 16 * 1024) {
+		priv->page_size = mtd->writesize / 2048;
+
 		setbits32(&lbc->bank[priv->bank].or, OR_FCM_PGS);
 		/* adjust ecc setup if needed */
 		if ((in_be32(&lbc->bank[priv->bank].br) & BR_DECC) ==
@@ -891,6 +1054,19 @@ static int __devinit fsl_elbc_nand_probe(struct platform_device *pdev)
 			goto err;
 		}
 		elbc_fcm_ctrl->counter++;
+		/*
+		 * Freescale FCM controller has a 2K size limitation of buffer
+		 * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
+		 * of chip is greater than 2048.
+		 * We malloc a large enough buffer (maximum page size is 16K).
+		 */
+		elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL);
+		if (!elbc_fcm_ctrl->buffer) {
+			dev_err(dev, "failed to allocate memory\n");
+			mutex_unlock(&fsl_elbc_nand_mutex);
+			ret = -ENOMEM;
+			goto err;
+		}
 
 		spin_lock_init(&elbc_fcm_ctrl->controller.lock);
 		init_waitqueue_head(&elbc_fcm_ctrl->controller.wq);
@@ -960,6 +1136,7 @@ static int fsl_elbc_nand_remove(struct platform_device *pdev)
 	elbc_fcm_ctrl->counter--;
 	if (!elbc_fcm_ctrl->counter) {
 		fsl_lbc_ctrl_dev->nand = NULL;
+		kfree(elbc_fcm_ctrl->buffer);
 		kfree(elbc_fcm_ctrl);
 	}
 	mutex_unlock(&fsl_elbc_nand_mutex);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
@ 2011-11-24  7:37   ` Li Yang-R58472
  2011-11-28 17:20     ` Scott Wood
  2011-11-24  7:41   ` Artem Bityutskiy
  2011-11-28 21:48   ` Scott Wood
  2 siblings, 1 reply; 14+ messages in thread
From: Li Yang-R58472 @ 2011-11-24  7:37 UTC (permalink / raw)
  To: Liu Shuo-B35362, dwmw2@infradead.org, Artem.Bityutskiy@nokia.com,
	Wood Scott-B07421
  Cc: linuxppc-dev@lists.ozlabs.org, akpm@linux-foundation.org,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org

PiBTdWJqZWN0OiBbUEFUQ0ggMy8zXSBtdGQvbmFuZCA6IHdvcmthcm91bmQgZm9yIEZyZWVzY2Fs
ZSBGQ00gdG8gc3VwcG9ydA0KPiBsYXJnZS1wYWdlIE5hbmQgY2hpcA0KPiANCj4gRnJvbTogTGl1
IFNodW8gPGIzNTM2MkBmcmVlc2NhbGUuY29tPg0KPiANCj4gRnJlZXNjYWxlIEZDTSBjb250cm9s
bGVyIGhhcyBhIDJLIHNpemUgbGltaXRhdGlvbiBvZiBidWZmZXIgUkFNLiBJbiBvcmRlcg0KPiB0
byBzdXBwb3J0IHRoZSBOYW5kIGZsYXNoIGNoaXAgd2hvc2UgcGFnZSBzaXplIGlzIGxhcmdlciB0
aGFuIDJLIGJ5dGVzLA0KPiB3ZSByZWFkL3dyaXRlIDJrIGRhdGEgcmVwZWF0ZWRseSBieSBpc3N1
aW5nIEZJUl9PUF9SQi9GSVJfT1BfV0IgYW5kIHNhdmUNCj4gdGhlbSB0byBhIGxhcmdlIGJ1ZmZl
ci4NCj4gDQo+IFNpZ25lZC1vZmYtYnk6IExpdSBTaHVvIDxiMzUzNjJAZnJlZXNjYWxlLmNvbT4N
Cj4gU2lnbmVkLW9mZi1ieTogTGkgWWFuZyA8bGVvbGlAZnJlZXNjYWxlLmNvbT4NCj4gLS0tDQo+
ICBkcml2ZXJzL210ZC9uYW5kL2ZzbF9lbGJjX25hbmQuYyB8ICAyMTENCj4gKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKystLS0NCj4gIDEgZmlsZXMgY2hhbmdlZCwgMTk0IGluc2Vy
dGlvbnMoKyksIDE3IGRlbGV0aW9ucygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvbXRk
L25hbmQvZnNsX2VsYmNfbmFuZC5jIGIvZHJpdmVycy9tdGQvbmFuZC9mc2xfZWxiY19uYW5kLmMN
Cj4gaW5kZXggZDYzNGM1Zi4uYzk2ZTcxNCAxMDA2NDQNCj4gLS0tIGEvZHJpdmVycy9tdGQvbmFu
ZC9mc2xfZWxiY19uYW5kLmMNCj4gKysrIGIvZHJpdmVycy9tdGQvbmFuZC9mc2xfZWxiY19uYW5k
LmMNCg0KW3NuaXBdDQoNCj4gK3N0YXRpYyB2b2lkIGlvX3RvX2J1ZmZlcihzdHJ1Y3QgbXRkX2lu
Zm8gKm10ZCwgaW50IHN1YnBhZ2UsIGludCBvb2IpDQo+ICt7DQo+ICsJc3RydWN0IG5hbmRfY2hp
cCAqY2hpcCA9IG10ZC0+cHJpdjsNCj4gKwlzdHJ1Y3QgZnNsX2VsYmNfbXRkICpwcml2ID0gY2hp
cC0+cHJpdjsNCj4gKwlzdHJ1Y3QgZnNsX2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmwgPSBw
cml2LT5jdHJsLT5uYW5kOw0KPiArCXZvaWQgKnNyYywgKmRzdDsNCj4gKwlpbnQgbGVuID0gKG9v
YiA/IDY0IDogMjA0OCk7DQo+ICsNCj4gKwlpZiAob29iKQ0KPiArCQlkc3QgPSBlbGJjX2ZjbV9j
dHJsLT5idWZmZXIgKyBtdGQtPndyaXRlc2l6ZSArIHN1YnBhZ2UgKiA2NDsNCj4gKwllbHNlDQo+
ICsJCWRzdCA9IGVsYmNfZmNtX2N0cmwtPmJ1ZmZlciArIHN1YnBhZ2UgKiAyMDQ4Ow0KPiArDQo+
ICsJc3JjID0gZWxiY19mY21fY3RybC0+YWRkciArIChvb2IgPyAyMDQ4IDogMCk7DQo+ICsJbWVt
Y3B5X2Zyb21pbyhkc3QsIHNyYywgbGVuKTsNCg0KTWlnaHQgYmUgc2FmZXIgdG8gdXNlIF9tZW1j
cHlfZnJvbWlvKCkNCg0KPiArfQ0KPiArDQo+ICtzdGF0aWMgdm9pZCBidWZmZXJfdG9faW8oc3Ry
dWN0IG10ZF9pbmZvICptdGQsIGludCBzdWJwYWdlLCBpbnQgb29iKQ0KPiArew0KPiArCXN0cnVj
dCBuYW5kX2NoaXAgKmNoaXAgPSBtdGQtPnByaXY7DQo+ICsJc3RydWN0IGZzbF9lbGJjX210ZCAq
cHJpdiA9IGNoaXAtPnByaXY7DQo+ICsJc3RydWN0IGZzbF9lbGJjX2ZjbV9jdHJsICplbGJjX2Zj
bV9jdHJsID0gcHJpdi0+Y3RybC0+bmFuZDsNCj4gKwl2b2lkICpzcmMsICpkc3Q7DQo+ICsJaW50
IGxlbiA9IChvb2IgPyA2NCA6IDIwNDgpOw0KPiArDQo+ICsJaWYgKG9vYikNCj4gKwkJc3JjID0g
ZWxiY19mY21fY3RybC0+YnVmZmVyICsgbXRkLT53cml0ZXNpemUgKyBzdWJwYWdlICogNjQ7DQo+
ICsJZWxzZQ0KPiArCQlzcmMgPSBlbGJjX2ZjbV9jdHJsLT5idWZmZXIgKyBzdWJwYWdlICogMjA0
ODsNCj4gKw0KPiArCWRzdCA9IGVsYmNfZmNtX2N0cmwtPmFkZHIgKyAob29iID8gMjA0OCA6IDAp
Ow0KPiArCW1lbWNweV90b2lvKGRzdCwgc3JjLCBsZW4pOw0KPiArDQo+ICsJLyogU2VlIHRoZSBp
bl84KCkgaW4gZnNsX2VsYmNfd3JpdGVfYnVmKCkgKi8NCj4gKwlpbl84KGVsYmNfZmNtX2N0cmwt
PmFkZHIpOw0KDQpTaG91bGQgYmUgc2FmZXIgdG8gcmVhZCBiYWNrIHRoZSBsYXN0IGNoYXIuDQoN
Ci0gTGVvDQo=

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
  2011-11-24  7:37   ` Li Yang-R58472
@ 2011-11-24  7:41   ` Artem Bityutskiy
  2011-11-24  7:49     ` Li Yang-R58472
  2011-11-28 21:48   ` Scott Wood
  2 siblings, 1 reply; 14+ messages in thread
From: Artem Bityutskiy @ 2011-11-24  7:41 UTC (permalink / raw)
  To: b35362
  Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd,
	scottwood, akpm, dwmw2

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

On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
> +               /*
> +                * Freescale FCM controller has a 2K size limitation of buffer
> +                * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> +                * of chip is greater than 2048.
> +                * We malloc a large enough buffer (maximum page size is 16K).
> +                */
> +               elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024, GFP_KERNEL); 

Are there NANDs with 16KiB page size?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  7:41   ` Artem Bityutskiy
@ 2011-11-24  7:49     ` Li Yang-R58472
  2011-11-24  8:16       ` Artem Bityutskiy
  0 siblings, 1 reply; 14+ messages in thread
From: Li Yang-R58472 @ 2011-11-24  7:49 UTC (permalink / raw)
  To: dedekind1@gmail.com, Liu Shuo-B35362
  Cc: Artem.Bityutskiy@nokia.com, Wood Scott-B07421,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
	dwmw2@infradead.org

PiBTdWJqZWN0OiBSZTogW1BBVENIIDMvM10gbXRkL25hbmQgOiB3b3JrYXJvdW5kIGZvciBGcmVl
c2NhbGUgRkNNIHRvIHN1cHBvcnQNCj4gbGFyZ2UtcGFnZSBOYW5kIGNoaXANCj4gDQo+IE9uIFRo
dSwgMjAxMS0xMS0yNCBhdCAwODo0MSArMDgwMCwgYjM1MzYyQGZyZWVzY2FsZS5jb20gd3JvdGU6
DQo+ID4gKyAgICAgICAgICAgICAgIC8qDQo+ID4gKyAgICAgICAgICAgICAgICAqIEZyZWVzY2Fs
ZSBGQ00gY29udHJvbGxlciBoYXMgYSAySyBzaXplIGxpbWl0YXRpb24gb2YgYnVmZmVyDQo+ID4g
KyAgICAgICAgICAgICAgICAqIFJBTSwgc28gZWxiY19mY21fY3RybC0+YnVmZmVyIGhhdmUgdG8g
YmUgdXNlZCBpZiB3cml0ZXNpemUNCj4gPiArICAgICAgICAgICAgICAgICogb2YgY2hpcCBpcyBn
cmVhdGVyIHRoYW4gMjA0OC4NCj4gPiArICAgICAgICAgICAgICAgICogV2UgbWFsbG9jIGEgbGFy
Z2UgZW5vdWdoIGJ1ZmZlciAobWF4aW11bSBwYWdlIHNpemUgaXMNCj4gMTZLKS4NCj4gPiArICAg
ICAgICAgICAgICAgICovDQo+ID4gKyAgICAgICAgICAgICAgIGVsYmNfZmNtX2N0cmwtPmJ1ZmZl
ciA9IGttYWxsb2MoMTAyNCAqIDE2ICsgMTAyNCwNCj4gR0ZQX0tFUk5FTCk7DQo+IA0KPiBBcmUg
dGhlcmUgTkFORHMgd2l0aCAxNktpQiBwYWdlIHNpemU/DQoNCldlIGFyZSBub3Qgc3VyZSwgYnV0
IGFyZSB0aGVyZSBwb3NzaWJpbGl0eSB0aGF0IGNoaXAgd2l0aCAxNksgcGFnZSB3aWxsIGFwcGVh
cj8gIE9yIG1heWJlIHdlIGNhbiBhZGQgYSBNQUNSTyBmb3IgdGhlIG1heGltdW0gcGFnZSBzaXpl
Pw0KDQotIExlbw0K

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  7:49     ` Li Yang-R58472
@ 2011-11-24  8:16       ` Artem Bityutskiy
  2011-11-24 10:02         ` LiuShuo
  0 siblings, 1 reply; 14+ messages in thread
From: Artem Bityutskiy @ 2011-11-24  8:16 UTC (permalink / raw)
  To: Li Yang-R58472
  Cc: Wood Scott-B07421, Artem.Bityutskiy@nokia.com,
	linuxppc-dev@lists.ozlabs.org, Liu Shuo-B35362,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	akpm@linux-foundation.org, dwmw2@infradead.org

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

On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
> > Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
> > large-page Nand chip
> > 
> > On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
> > > +               /*
> > > +                * Freescale FCM controller has a 2K size limitation of buffer
> > > +                * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> > > +                * of chip is greater than 2048.
> > > +                * We malloc a large enough buffer (maximum page size is
> > 16K).
> > > +                */
> > > +               elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,
> > GFP_KERNEL);
> > 
> > Are there NANDs with 16KiB page size?
> 
> We are not sure, but are there possibility that chip with 16K page will appear?  Or maybe we can add a MACRO for the maximum page size?

I do not know, but I know that allocating 32KiB of contiguous physical
RAM may cause unneeded memory pressure and even fail if the memory is
too fragmented. So I would not go for this unless this is necessary.

Did you try to look how the NAND base interface could be changed to
avoid re-allocation altogether, BTW?

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  8:16       ` Artem Bityutskiy
@ 2011-11-24 10:02         ` LiuShuo
  2011-11-24 11:07           ` Artem Bityutskiy
  0 siblings, 1 reply; 14+ messages in thread
From: LiuShuo @ 2011-11-24 10:02 UTC (permalink / raw)
  To: dedekind1
  Cc: Artem.Bityutskiy@nokia.com, Li Yang-R58472, Wood Scott-B07421,
	dwmw2@infradead.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org

=E4=BA=8E 2011=E5=B9=B411=E6=9C=8824=E6=97=A5 16:16, Artem Bityutskiy =E5=
=86=99=E9=81=93:
> On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
>>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to s=
upport
>>> large-page Nand chip
>>>
>>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
>>>> +               /*
>>>> +                * Freescale FCM controller has a 2K size limitation=
 of buffer
>>>> +                * RAM, so elbc_fcm_ctrl->buffer have to be used if =
writesize
>>>> +                * of chip is greater than 2048.
>>>> +                * We malloc a large enough buffer (maximum page siz=
e is
>>> 16K).
>>>> +                */
>>>> +               elbc_fcm_ctrl->buffer =3D kmalloc(1024 * 16 + 1024,
>>> GFP_KERNEL);
>>>
>>> Are there NANDs with 16KiB page size?
>> We are not sure, but are there possibility that chip with 16K page wil=
l appear?  Or maybe we can add a MACRO for the maximum page size?
> I do not know, but I know that allocating 32KiB of contiguous physical
> RAM may cause unneeded memory pressure and even fail if the memory is
> too fragmented. So I would not go for this unless this is necessary.
What is your suggestion ? 8k is enough ?
> Did you try to look how the NAND base interface could be changed to
> avoid re-allocation altogether, BTW?
This buffer is a controller-wide resource( as Scott said), I only=20
allocate buffer one time in this version.
It should be a large enough buffer for all chips.

-Liu Shuo

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24 10:02         ` LiuShuo
@ 2011-11-24 11:07           ` Artem Bityutskiy
  0 siblings, 0 replies; 14+ messages in thread
From: Artem Bityutskiy @ 2011-11-24 11:07 UTC (permalink / raw)
  To: LiuShuo
  Cc: Artem.Bityutskiy@nokia.com, Li Yang-R58472, Wood Scott-B07421,
	dwmw2@infradead.org, linux-kernel@vger.kernel.org,
	linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
	linuxppc-dev@lists.ozlabs.org

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

On Thu, 2011-11-24 at 18:02 +0800, LiuShuo wrote:
> 于 2011年11月24日 16:16, Artem Bityutskiy 写道:
> > On Thu, 2011-11-24 at 07:49 +0000, Li Yang-R58472 wrote:
> >>> Subject: Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support
> >>> large-page Nand chip
> >>>
> >>> On Thu, 2011-11-24 at 08:41 +0800, b35362@freescale.com wrote:
> >>>> +               /*
> >>>> +                * Freescale FCM controller has a 2K size limitation of buffer
> >>>> +                * RAM, so elbc_fcm_ctrl->buffer have to be used if writesize
> >>>> +                * of chip is greater than 2048.
> >>>> +                * We malloc a large enough buffer (maximum page size is
> >>> 16K).
> >>>> +                */
> >>>> +               elbc_fcm_ctrl->buffer = kmalloc(1024 * 16 + 1024,
> >>> GFP_KERNEL);
> >>>
> >>> Are there NANDs with 16KiB page size?
> >> We are not sure, but are there possibility that chip with 16K page will appear?  Or maybe we can add a MACRO for the maximum page size?
> > I do not know, but I know that allocating 32KiB of contiguous physical
> > RAM may cause unneeded memory pressure and even fail if the memory is
> > too fragmented. So I would not go for this unless this is necessary.
> What is your suggestion ? 8k is enough ?

Up to you, I do not have suggestions, just expressed a concern. I'd keep
the buffer smaller if possible. By the time 16KiB pages appear, your HW
may retire already :-)

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  7:37   ` Li Yang-R58472
@ 2011-11-28 17:20     ` Scott Wood
  0 siblings, 0 replies; 14+ messages in thread
From: Scott Wood @ 2011-11-28 17:20 UTC (permalink / raw)
  To: Li Yang-R58472
  Cc: Wood Scott-B07421, Artem.Bityutskiy@nokia.com,
	linuxppc-dev@lists.ozlabs.org, Liu Shuo-B35362,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	akpm@linux-foundation.org, dwmw2@infradead.org

On 11/24/2011 01:37 AM, Li Yang-R58472 wrote:
>> +static void io_to_buffer(struct mtd_info *mtd, int subpage, int oob)
>> +{
>> +	struct nand_chip *chip = mtd->priv;
>> +	struct fsl_elbc_mtd *priv = chip->priv;
>> +	struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = priv->ctrl->nand;
>> +	void *src, *dst;
>> +	int len = (oob ? 64 : 2048);
>> +
>> +	if (oob)
>> +		dst = elbc_fcm_ctrl->buffer + mtd->writesize + subpage * 64;
>> +	else
>> +		dst = elbc_fcm_ctrl->buffer + subpage * 2048;
>> +
>> +	src = elbc_fcm_ctrl->addr + (oob ? 2048 : 0);
>> +	memcpy_fromio(dst, src, len);
> 
> Might be safer to use _memcpy_fromio()

How so?

memcpy_fromio() is the public interface that will end up calling
_memcpy_fromio() on powerpc.

-Scott

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
  2011-11-24  7:37   ` Li Yang-R58472
  2011-11-24  7:41   ` Artem Bityutskiy
@ 2011-11-28 21:48   ` Scott Wood
  2011-11-28 21:49     ` Scott Wood
  2 siblings, 1 reply; 14+ messages in thread
From: Scott Wood @ 2011-11-28 21:48 UTC (permalink / raw)
  To: LiuShuo
  Cc: Artem Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
	David Woodhouse

On 11/23/2011 06:41 PM, b35362@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
> 
> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
> to support the Nand flash chip whose page size is larger than 2K bytes,
> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
> them to a large buffer.
> 
> Signed-off-by: Liu Shuo <b35362@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
>  drivers/mtd/nand/fsl_elbc_nand.c |  211 +++++++++++++++++++++++++++++++++++---
>  1 files changed, 194 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> index d634c5f..c96e714 100644
> --- a/drivers/mtd/nand/fsl_elbc_nand.c
> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> @@ -55,7 +55,9 @@ struct fsl_elbc_mtd {
>  	struct device *dev;
>  	int bank;               /* Chip select bank number           */
>  	u8 __iomem *vbase;      /* Chip select base virtual address  */
> -	int page_size;          /* NAND page size (0=512, 1=2048)    */
> +	int page_size;          /* NAND page size, the mutiple of 2048.
> +				 * (0=512, 1=2048, 2=4096, 4=8192....)
> +				 */

Again, please remove this.  It was sort-of reasonable when it was a
boolean that selected between slightly different programming models.  It
doesn't make sense as "mtd->writesize == 512 ? 0 : mtd->writesize / 512".

What is the plan for migrating bad block markers on first use?

-Scott

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
  2011-11-28 21:48   ` Scott Wood
@ 2011-11-28 21:49     ` Scott Wood
  0 siblings, 0 replies; 14+ messages in thread
From: Scott Wood @ 2011-11-28 21:49 UTC (permalink / raw)
  To: LiuShuo
  Cc: Artem Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd, akpm,
	David Woodhouse

On 11/28/2011 03:48 PM, Scott Wood wrote:
> On 11/23/2011 06:41 PM, b35362@freescale.com wrote:
>> From: Liu Shuo <b35362@freescale.com>
>>
>> Freescale FCM controller has a 2K size limitation of buffer RAM. In order
>> to support the Nand flash chip whose page size is larger than 2K bytes,
>> we read/write 2k data repeatedly by issuing FIR_OP_RB/FIR_OP_WB and save
>> them to a large buffer.
>>
>> Signed-off-by: Liu Shuo <b35362@freescale.com>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>>  drivers/mtd/nand/fsl_elbc_nand.c |  211 +++++++++++++++++++++++++++++++++++---
>>  1 files changed, 194 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
>> index d634c5f..c96e714 100644
>> --- a/drivers/mtd/nand/fsl_elbc_nand.c
>> +++ b/drivers/mtd/nand/fsl_elbc_nand.c
>> @@ -55,7 +55,9 @@ struct fsl_elbc_mtd {
>>  	struct device *dev;
>>  	int bank;               /* Chip select bank number           */
>>  	u8 __iomem *vbase;      /* Chip select base virtual address  */
>> -	int page_size;          /* NAND page size (0=512, 1=2048)    */
>> +	int page_size;          /* NAND page size, the mutiple of 2048.
>> +				 * (0=512, 1=2048, 2=4096, 4=8192....)
>> +				 */
> 
> Again, please remove this.  It was sort-of reasonable when it was a
> boolean that selected between slightly different programming models.  It
> doesn't make sense as "mtd->writesize == 512 ? 0 : mtd->writesize / 512".

Sorry, I meant "mtd->writesize == 512 ? 0 : mtd->writesize / 2048".

-Scott

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR
@ 2011-12-04  4:31 shuo.liu
  2011-12-05  6:50 ` Artem Bityutskiy
  0 siblings, 1 reply; 14+ messages in thread
From: shuo.liu @ 2011-12-04  4:31 UTC (permalink / raw)
  To: dwmw2, Artem.Bityutskiy, scottwood
  Cc: linux-kernel, shuo.liu, linux-mtd, akpm, linuxppc-dev

From: Liu Shuo <b35362@freescale.com>

On both of large-page chip and small-page chip, we always should use
'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
use a overflowed 'column' to set it.

Signed-off-by: Liu Shuo <b35362@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
 drivers/mtd/nand/fsl_elbc_nand.c |   18 +++++++++++-------
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index cc08a11..6fce7da 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -414,9 +414,17 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 		         page_addr, column);
 
 		elbc_fcm_ctrl->column = column;
-		elbc_fcm_ctrl->oob = 0;
 		elbc_fcm_ctrl->use_mdr = 1;
 
+		if (column >= mtd->writesize) {
+			/* OOB area */
+			column -= mtd->writesize;
+			elbc_fcm_ctrl->oob = 1;
+		} else {
+			WARN_ON(column != 0);
+			elbc_fcm_ctrl->oob = 0;
+		}
+
 		fcr = (NAND_CMD_STATUS   << FCR_CMD1_SHIFT) |
 		      (NAND_CMD_SEQIN    << FCR_CMD2_SHIFT) |
 		      (NAND_CMD_PAGEPROG << FCR_CMD3_SHIFT);
@@ -441,16 +449,12 @@ static void fsl_elbc_cmdfunc(struct mtd_info *mtd, unsigned int command,
 			         (FIR_OP_CW1 << FIR_OP6_SHIFT) |
 			         (FIR_OP_RS  << FIR_OP7_SHIFT));
 
-			if (column >= mtd->writesize) {
+			if (elbc_fcm_ctrl->oob)
 				/* OOB area --> READOOB */
-				column -= mtd->writesize;
 				fcr |= NAND_CMD_READOOB << FCR_CMD0_SHIFT;
-				elbc_fcm_ctrl->oob = 1;
-			} else {
-				WARN_ON(column != 0);
+			else
 				/* First 256 bytes --> READ0 */
 				fcr |= NAND_CMD_READ0 << FCR_CMD0_SHIFT;
-			}
 		}
 
 		out_be32(&lbc->fcr, fcr);
-- 
1.7.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR
  2011-12-04  4:31 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR shuo.liu
@ 2011-12-05  6:50 ` Artem Bityutskiy
  0 siblings, 0 replies; 14+ messages in thread
From: Artem Bityutskiy @ 2011-12-05  6:50 UTC (permalink / raw)
  To: shuo.liu
  Cc: Artem.Bityutskiy, linuxppc-dev, linux-kernel, linux-mtd,
	scottwood, akpm, dwmw2

On Sun, 2011-12-04 at 12:31 +0800, shuo.liu@freescale.com wrote:
> From: Liu Shuo <b35362@freescale.com>
> 
> On both of large-page chip and small-page chip, we always should use
> 'elbc_fcm_ctrl->oob' to set the FPAR_LP_MS/FPAR_SP_MS bit of FPAR, don't
> use a overflowed 'column' to set it.
> 
> Signed-off-by: Liu Shuo <b35362@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>

Pushed patches 1 and 2 to l2-mtd-2.6.git, thanks!

Artem.

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2011-12-05  6:50 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-24  0:41 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR b35362
2011-11-24  0:41 ` [PATCH 2/3] mtd/nand : set correct length to FBCR for a non-full-page write b35362
2011-11-24  0:41 ` [PATCH 3/3] mtd/nand : workaround for Freescale FCM to support large-page Nand chip b35362
2011-11-24  7:37   ` Li Yang-R58472
2011-11-28 17:20     ` Scott Wood
2011-11-24  7:41   ` Artem Bityutskiy
2011-11-24  7:49     ` Li Yang-R58472
2011-11-24  8:16       ` Artem Bityutskiy
2011-11-24 10:02         ` LiuShuo
2011-11-24 11:07           ` Artem Bityutskiy
2011-11-28 21:48   ` Scott Wood
2011-11-28 21:49     ` Scott Wood
  -- strict thread matches above, loose matches on Subject: below --
2011-12-04  4:31 [PATCH 1/3] mtd/nand : use elbc_fcm_ctrl->oob to set FPAR_MS bit of FPAR shuo.liu
2011-12-05  6:50 ` Artem Bityutskiy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).