* [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).