diff options
Diffstat (limited to 'drivers/mtd/nand/gpmi-nand/gpmi-lib.c')
| -rw-r--r-- | drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 18 |
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 7f680420bfab..7db6555ed3ba 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 | */ |
| 82 | int gpmi_reset_block(void __iomem *reset_addr, bool just_enable) | 84 | static 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 | ||
