All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: nsnehaprabha@ti.com, akpm@linux-foundation.org,
	linux-mtd@lists.infradead.org,
	davinci-linux-open-source@linux.davincidsp.com,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd-nand: davinci: Correct 4-bit error correction
Date: Tue, 10 Nov 2009 17:05:02 +0200	[thread overview]
Message-ID: <1257865502.21596.773.camel@localhost> (raw)
In-Reply-To: <1257244270-2433-1-git-send-email-sudhakar.raj@ti.com>

On Tue, 2009-11-03 at 16:01 +0530, Sudhakar Rajashekhara wrote:
> 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>
> ---
>  drivers/mtd/nand/davinci_nand.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index fe3eba8..8a32999 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -310,6 +310,7 @@ 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;
>  
>  	/* All bytes 0xff?  It's an erased page; ignore its ECC. */
> @@ -360,6 +361,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);
> +
>  	for (;;) {
>  		u32	fsr = davinci_nand_readl(info, NANDFSR_OFFSET);

I see a lot of constructs like this in many mtd drivers. I wonder, what
happens if ecc_state never becomes < 4? Should there be some protection
against this, e.g., exit the loop with an error message if we are
looping for more than 1 or several seconds?

What is the "official" / "right" way for this kind of loops?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Cc: linux-mtd@lists.infradead.org, akpm@linux-foundation.org,
	nsnehaprabha@ti.com,
	davinci-linux-open-source@linux.davincidsp.com,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mtd-nand: davinci: Correct 4-bit error correction
Date: Tue, 10 Nov 2009 17:05:02 +0200	[thread overview]
Message-ID: <1257865502.21596.773.camel@localhost> (raw)
In-Reply-To: <1257244270-2433-1-git-send-email-sudhakar.raj@ti.com>

On Tue, 2009-11-03 at 16:01 +0530, Sudhakar Rajashekhara wrote:
> 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>
> ---
>  drivers/mtd/nand/davinci_nand.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index fe3eba8..8a32999 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -310,6 +310,7 @@ 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;
>  
>  	/* All bytes 0xff?  It's an erased page; ignore its ECC. */
> @@ -360,6 +361,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);
> +
>  	for (;;) {
>  		u32	fsr = davinci_nand_readl(info, NANDFSR_OFFSET);

I see a lot of constructs like this in many mtd drivers. I wonder, what
happens if ecc_state never becomes < 4? Should there be some protection
against this, e.g., exit the loop with an error message if we are
looping for more than 1 or several seconds?

What is the "official" / "right" way for this kind of loops?

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)


  reply	other threads:[~2009-11-10 15:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 10:31 [PATCH] mtd-nand: davinci: Correct 4-bit error correction Sudhakar Rajashekhara
2009-11-10 15:05 ` Artem Bityutskiy [this message]
2009-11-10 15:05   ` Artem Bityutskiy
  -- strict thread matches above, loose matches on Subject: below --
2010-07-09  5:29 [PATCH] mtd-nand: davinci: correct " Sudhakar Rajashekhara
2010-07-09 22:39 ` Andrew Morton
2010-07-12  6:28   ` Sudhakar Rajashekhara
2010-07-13  9:32     ` Sudhakar Rajashekhara
2010-07-13 17:41       ` Andrew Morton
2010-07-14 11:25         ` Sudhakar Rajashekhara

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=1257865502.21596.773.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nsnehaprabha@ti.com \
    --cc=sudhakar.raj@ti.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.