RFC fsl_elbc_nand.c does not update mtd->ecc_stats
Michael Hench
michaelhench at gmail.com
Fri Jul 22 09:06:53 EDT 2011
when using the fsl_elbc_nand driver, mtd->ecc_stats does not appear to
get updated
UBI uses this to determine when to scrub blocks
the patch below appears to fix this (draft 0)
am I missing anything?
does this look reasonable?
diff -purN orig/drivers/mtd/nand/fsl_elbc_nand.c
linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c
--- orig/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22 07:02:37.908778052 -0500
+++ linux-3.0-rc7/drivers/mtd/nand/fsl_elbc_nand.c 2011-07-22
06:56:09.655002047 -0500
@@ -748,12 +748,43 @@ static int fsl_elbc_read_page(struct mtd
uint8_t *buf,
int page)
{
+ struct fsl_elbc_mtd *priv = chip->priv;
+ struct fsl_lbc_ctrl *ctrl = priv->ctrl;
+ struct fsl_lbc_regs __iomem *lbc = ctrl->regs;
+ uint32_t lteccr;
+
fsl_elbc_read_buf(mtd, buf, mtd->writesize);
fsl_elbc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
if (fsl_elbc_wait(mtd, chip) & NAND_STATUS_FAIL)
mtd->ecc_stats.failed++;
+ if(chip->ecc.mode != NAND_ECC_HW)
+ return(0);
+
+ /* get the hardware ECC results */
+ lteccr = in_be32(&lbc->lteccr);
+ if(lteccr & 0x000F000F) {
+ int i;
+
+ out_be32(&lbc->lteccr, -1); /* clear lteccr */
+ printk(KERN_ERR "ECC RESULT %x n=%d",
+ lteccr, mtd->ecc_stats.corrected);
+ /*
+ * 4 bits, one for each 512 byte subpage
+ * 12-15 (ppc order) are for successfully corrected
+ * 28-31 are for failed
+ * small page nand has 3 bits set to zero in each field
+ */
+ for(i=0; i < 4; i++) {
+ if(lteccr & 0x10000)
+ mtd->ecc_stats.corrected++;
+ if(lteccr & 0x1)
+ mtd->ecc_stats.failed++;
+ lteccr >>= 1;
+ }
+ }
+
return 0;
}
More information about the linux-mtd
mailing list