| commit | 6f2a6a52560ad8d85710aabd92b7a3239b3a6b07 | |
| author | Wolfram Sang <w.sang@pengutronix.de> | |
| Wed, 5 Dec 2012 20:46:02 +0000 (5 21:46 +0100) | ||
| committer | Artem Bityutskiy <artem.bityutskiy@linux.intel.com> | |
| Thu, 13 Dec 2012 11:39:32 +0000 (13 13:39 +0200) | ||
| tree | b4b172b85db65e315ded52832bc827ba5f2693a2 | treesnapshot (tar.gz zip) |
| parent | 3c9c6d657a94f9b9aae498cb5951659cc67fd6ad | commitdiff |
mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems
It could happen (1 out of 100 times) that NAND did not start up
correctly after warm rebooting, so the kernel could not find the UBI or
DMA timed out due to a stalled BCH. When resetting BCH together with
GPMI, the issue could not be observed anymore (after 10000+ reboots). We
probably need the consistent state already before sending any command to
NAND, even when no ECC is needed. I chose to keep the extra reset for
BCH when changing the flash layout to be on the safe side.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
It could happen (1 out of 100 times) that NAND did not start up
correctly after warm rebooting, so the kernel could not find the UBI or
DMA timed out due to a stalled BCH. When resetting BCH together with
GPMI, the issue could not be observed anymore (after 10000+ reboots). We
probably need the consistent state already before sending any command to
NAND, even when no ECC is needed. I chose to keep the extra reset for
BCH when changing the flash layout to be on the safe side.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Acked-by: Huang Shijie <b32955@freescale.com>
Cc: stable@vger.kernel.org
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
| drivers/mtd/nand/gpmi-nand/gpmi-lib.c | diffblobblamehistory |