All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Huang Shijie <b32955@freescale.com>
Cc: baruch@tkos.co.il, koen.beel.barco@gmail.com,
	w.sang@pengutronix.de, linux-mtd@lists.infradead.org,
	Artem.Bityutskiy@intel.com, shijie8@gmail.com,
	linux-arm-kernel@lists.infradead.org, LW@karo-electronics.de
Subject: Re: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Fri, 30 Dec 2011 15:01:07 +0100	[thread overview]
Message-ID: <201112301501.07351.marek.vasut@gmail.com> (raw)
In-Reply-To: <1325233646-3343-1-git-send-email-b32955@freescale.com>

> In MX28, if we do not reset the BCH module. The BCH module may
> becomes unstable when the board reboots for several thousands times.
> This bug has been catched in customer's production.
> 
> The patch adds some comments, and fixes it now.
> 
> Also change gpmi_reset_block() to static.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c index de4db76..1573e99 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -69,7 +69,8 @@ static int clear_poll_bit(void __iomem *addr, u32 mask)
>   *  [1] enable the module.
>   *  [2] reset the module.
>   *
> - * In most of the cases, it's ok. But there is a hardware bug in the BCH
> block. + * In most of the cases, it's ok.
> + * But in MX23, there is a hardware bug in the BCH block.
>   * If you try to soft reset the BCH block, it becomes unusable until
>   * the next hard reset. This case occurs in the NAND boot mode. When the
> board * boots by NAND, the ROM of the chip will initialize the BCH blocks
> itself. @@ -78,8 +79,10 @@ static int clear_poll_bit(void __iomem *addr,
> u32 mask) *
>   * To avoid this bug, just add a new parameter `just_enable` for
>   * the mxs_reset_block(), and rewrite it here.
> + *
> + * The bug has been fixed in the following chips, such as MX28.
>   */
> -int gpmi_reset_block(void __iomem *reset_addr, bool just_enable)
> +static int gpmi_reset_block(void __iomem *reset_addr, bool just_enable)
>  {
>  	int ret;
>  	int timeout = 0x400;
> @@ -206,7 +209,8 @@ int bch_set_geometry(struct gpmi_nand_data *this)
>  	if (ret)
>  		goto err_out;
> 
> -	ret = gpmi_reset_block(r->bch_regs, true);
> +	/* The bug only exits in mx23, the following chips fix it. */
> +	ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
>  	if (ret)
>  		goto err_out;

Looks sane, though I can't test right now.

Acked-by: Marek Vasut <marek.vasut@gmail.com>

WARNING: multiple messages have this Message-ID (diff)
From: marek.vasut@gmail.com (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23
Date: Fri, 30 Dec 2011 15:01:07 +0100	[thread overview]
Message-ID: <201112301501.07351.marek.vasut@gmail.com> (raw)
In-Reply-To: <1325233646-3343-1-git-send-email-b32955@freescale.com>

> In MX28, if we do not reset the BCH module. The BCH module may
> becomes unstable when the board reboots for several thousands times.
> This bug has been catched in customer's production.
> 
> The patch adds some comments, and fixes it now.
> 
> Also change gpmi_reset_block() to static.
> 
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c |   10 +++++++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c index de4db76..1573e99 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> @@ -69,7 +69,8 @@ static int clear_poll_bit(void __iomem *addr, u32 mask)
>   *  [1] enable the module.
>   *  [2] reset the module.
>   *
> - * In most of the cases, it's ok. But there is a hardware bug in the BCH
> block. + * In most of the cases, it's ok.
> + * But in MX23, there is a hardware bug in the BCH block.
>   * If you try to soft reset the BCH block, it becomes unusable until
>   * the next hard reset. This case occurs in the NAND boot mode. When the
> board * boots by NAND, the ROM of the chip will initialize the BCH blocks
> itself. @@ -78,8 +79,10 @@ static int clear_poll_bit(void __iomem *addr,
> u32 mask) *
>   * To avoid this bug, just add a new parameter `just_enable` for
>   * the mxs_reset_block(), and rewrite it here.
> + *
> + * The bug has been fixed in the following chips, such as MX28.
>   */
> -int gpmi_reset_block(void __iomem *reset_addr, bool just_enable)
> +static int gpmi_reset_block(void __iomem *reset_addr, bool just_enable)
>  {
>  	int ret;
>  	int timeout = 0x400;
> @@ -206,7 +209,8 @@ int bch_set_geometry(struct gpmi_nand_data *this)
>  	if (ret)
>  		goto err_out;
> 
> -	ret = gpmi_reset_block(r->bch_regs, true);
> +	/* The bug only exits in mx23, the following chips fix it. */
> +	ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
>  	if (ret)
>  		goto err_out;

Looks sane, though I can't test right now.

Acked-by: Marek Vasut <marek.vasut@gmail.com>

  reply	other threads:[~2011-12-30 14:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30  8:27 [PATCH v2] MTD/GPMI bugfix : reset the BCH module when it is not MX23 Huang Shijie
2011-12-30  8:27 ` Huang Shijie
2011-12-30 14:01 ` Marek Vasut [this message]
2011-12-30 14:01   ` Marek Vasut
2011-12-30 14:36 ` Wolfram Sang
2011-12-30 14:36   ` Wolfram Sang
2011-12-31  2:23   ` Huang Shijie
2011-12-31  2:23     ` Huang Shijie
2011-12-31  3:15     ` Marek Vasut
2011-12-31  3:15       ` Marek Vasut
2011-12-31  3:31       ` Huang Shijie
2011-12-31  3:31         ` Huang Shijie
2011-12-31  4:45         ` Marek Vasut
2011-12-31  4:45           ` Marek Vasut
2011-12-31 15:43     ` Wolfram Sang
2011-12-31 15:43       ` Wolfram Sang
2012-01-01 15:23       ` Huang Shijie
2012-01-01 15:23         ` Huang Shijie
2012-01-01 22:33         ` Wolfram Sang
2012-01-01 22:33           ` Wolfram Sang
2012-01-03  2:30           ` Huang Shijie
2012-01-03  2:30             ` Huang Shijie
2012-01-03 11:11             ` Wolfram Sang
2012-01-03 11:11               ` Wolfram Sang
2012-01-04  2:43               ` Huang Shijie
2012-01-04  2:43                 ` Huang Shijie

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=201112301501.07351.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=Artem.Bityutskiy@intel.com \
    --cc=LW@karo-electronics.de \
    --cc=b32955@freescale.com \
    --cc=baruch@tkos.co.il \
    --cc=koen.beel.barco@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=shijie8@gmail.com \
    --cc=w.sang@pengutronix.de \
    /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.