aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/mtd
diff options
context:
space:
mode:
authorHuang Shijie <b32955@freescale.com>2012-01-03 22:18:46 -0500
committerDavid Woodhouse <David.Woodhouse@intel.com>2012-01-11 04:52:46 -0500
commit9398d1ce09b9009996f7d2468e1d3c785fa6feda (patch)
treef21d1bd73f86ca855f2425436ddd371001a7413e /drivers/mtd
parent12183a20a8baf009bf570ab3db45a27fd6b1fd03 (diff)
mtd: gpmi-nand bugfix: reset the BCH module when it is not MX23
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 (some from Wolfram Sang), and fixes it now. Also change gpmi_reset_block() to static. Signed-off-by: Huang Shijie <b32955@freescale.com> Acked-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@kernel.org [3.1+]
Diffstat (limited to 'drivers/mtd')
-rw-r--r--drivers/mtd/nand/gpmi-nand/gpmi-lib.c18
1 files changed, 14 insertions, 4 deletions
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 2a56fc6f399a..c56f8e021b90 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -69,17 +69,19 @@ static int clear_poll_bit(void __iomem *addr, u32 mask)
69 * [1] enable the module. 69 * [1] enable the module.
70 * [2] reset the module. 70 * [2] reset the module.
71 * 71 *
72 * In most of the cases, it's ok. But there is a hardware bug in the BCH block. 72 * In most of the cases, it's ok.
73 * But in MX23, there is a hardware bug in the BCH block (see erratum #2847).
73 * If you try to soft reset the BCH block, it becomes unusable until 74 * If you try to soft reset the BCH block, it becomes unusable until
74 * the next hard reset. This case occurs in the NAND boot mode. When the board 75 * the next hard reset. This case occurs in the NAND boot mode. When the board
75 * boots by NAND, the ROM of the chip will initialize the BCH blocks itself. 76 * boots by NAND, the ROM of the chip will initialize the BCH blocks itself.
76 * So If the driver tries to reset the BCH again, the BCH will not work anymore. 77 * So If the driver tries to reset the BCH again, the BCH will not work anymore.
77 * You will see a DMA timeout in this case. 78 * You will see a DMA timeout in this case. The bug has been fixed
79 * in the following chips, such as MX28.
78 * 80 *
79 * To avoid this bug, just add a new parameter `just_enable` for 81 * To avoid this bug, just add a new parameter `just_enable` for
80 * the mxs_reset_block(), and rewrite it here. 82 * the mxs_reset_block(), and rewrite it here.
81 */ 83 */
82int gpmi_reset_block(void __iomem *reset_addr, bool just_enable) 84static int gpmi_reset_block(void __iomem *reset_addr, bool just_enable)
83{ 85{
84 int ret; 86 int ret;
85 int timeout = 0x400; 87 int timeout = 0x400;
@@ -206,7 +208,15 @@ int bch_set_geometry(struct gpmi_nand_data *this)
206 if (ret) 208 if (ret)
207 goto err_out; 209 goto err_out;
208 210
209 ret = gpmi_reset_block(r->bch_regs, true); 211 /*
212 * Due to erratum #2847 of the MX23, the BCH cannot be soft reset on this
213 * chip, otherwise it will lock up. So we skip resetting BCH on the MX23.
214 * On the other hand, the MX28 needs the reset, because one case has been
215 * seen where the BCH produced ECC errors constantly after 10000
216 * consecutive reboots. The latter case has not been seen on the MX23 yet,
217 * still we don't know if it could happen there as well.
218 */
219 ret = gpmi_reset_block(r->bch_regs, GPMI_IS_MX23(this));
210 if (ret) 220 if (ret)
211 goto err_out; 221 goto err_out;
212 222