diff mbox

mtd-nand: davinci: correct 4-bit error correction

Message ID 1278653389-12019-1-git-send-email-sudhakar.raj@ti.com (mailing list archive)
State Changes Requested, archived
Headers show

Commit Message

Rajashekhara, Sudhakar July 9, 2010, 5:29 a.m. UTC 
On TI's DA830/OMAP-L137, DA850/OMAP-L138 and DM365, after setting the
4BITECC_ADD_CALC_START bit in the NAND Flash control register to 1 and
before waiting for the NAND Flash status register to be equal to 1, 2 or
3, we have to wait till the ECC HW goes to correction state.  Without this
wait, ECC correction calculations will not be proper.

This has been tested on DA830/OMAP-L137, DA850/OMAP-L138, DM355 and DM365
EVMs.

Signed-off-by: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Acked-by: Sneha Narnakaje <nsnehaprabha@ti.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
This patch applies on top of Linus's master.

This patch was present in -mm tree and was dropped because it was merged
into mainline. But now this patch is not present neither in Linus's tree
nor in linux-next. Hence resending it again.

 drivers/mtd/nand/davinci_nand.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

Comments

Andrew Morton July 9, 2010, 10:39 p.m. UTC | #1 
On Fri,  9 Jul 2010 10:59:49 +0530
Sudhakar Rajashekhara <sudhakar.raj@ti.com> wrote:

> +
> +	/*
> +	 * ECC_STATE field reads 0x3 (Error correction complete) immediately
> +	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
> +	 * begin trying to poll for the state, you may fall right out of your
> +	 * loop without any of the correction calculations having taken place.
> +	 * The recommendation from the hardware team is to wait till ECC_STATE
> +	 * reads less than 4, which means ECC HW has entered correction state.
> +	 */
> +	do {
> +		ecc_state = (davinci_nand_readl(info,
> +				NANDFSR_OFFSET) >> 8) & 0x0f;
> +		cpu_relax();
> +	} while ((ecc_state < 4) && time_before(jiffies, timeo));

An up-to-100-milliseond busy wait is pretty bad.  For how long do you
expect this to spin in practice?
diff mbox

Patch

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 9c9d893..2ac7367 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -311,7 +311,9 @@  static int nand_davinci_correct_4bit(struct mtd_info *mtd,
 	unsigned short ecc10[8];
 	unsigned short *ecc16;
 	u32 syndrome[4];
+	u32 ecc_state;
 	unsigned num_errors, corrected;
+	unsigned long timeo = jiffies + msecs_to_jiffies(100);
 
 	/* All bytes 0xff?  It's an erased page; ignore its ECC. */
 	for (i = 0; i < 10; i++) {
@@ -361,6 +363,21 @@  compare:
 	 */
 	davinci_nand_writel(info, NANDFCR_OFFSET,
 			davinci_nand_readl(info, NANDFCR_OFFSET) | BIT(13));
+
+	/*
+	 * ECC_STATE field reads 0x3 (Error correction complete) immediately
+	 * after setting the 4BITECC_ADD_CALC_START bit. So if you immediately
+	 * begin trying to poll for the state, you may fall right out of your
+	 * loop without any of the correction calculations having taken place.
+	 * The recommendation from the hardware team is to wait till ECC_STATE
+	 * reads less than 4, which means ECC HW has entered correction state.
+	 */
+	do {
+		ecc_state = (davinci_nand_readl(info,
+				NANDFSR_OFFSET) >> 8) & 0x0f;
+		cpu_relax();
+	} while ((ecc_state < 4) && time_before(jiffies, timeo));
+
 	for (;;) {
 		u32	fsr = davinci_nand_readl(info, NANDFSR_OFFSET);