OSDN Git Service

mtd: rawnand: micron: Get the actual number of bitflips
authorBoris Brezillon <boris.brezillon@bootlin.com>
Wed, 18 Jul 2018 08:42:19 +0000 (10:42 +0200)
committerMiquel Raynal <miquel.raynal@bootlin.com>
Thu, 19 Jul 2018 21:15:04 +0000 (23:15 +0200)
commit2301780711efc514a8bb183e853bda8decce746a
tree8cfe6457d6baf9df23eb53ebf96ee1074e61b060
parentcb2bf403a462082a253fe0a94cfec020285ffbd8
mtd: rawnand: micron: Get the actual number of bitflips

The MT29F2Gxxx chips with 4bits/512byte on-die ECC let us know when
some bitflips were corrected by the on-die ECC, but they do not report
the actual number of bitflips that were present in the data+ECC chunk.

We initially decided to always return ecc->strength to avoid re-reading
the page in raw mode + comparing it to the corrected buffer to extract
the real number of bitflips, but this forces UBI to move data around as
soon as one bitflip is present in a page.

This not only wears the NAND out faster, but also degrades
performances, since reading a full PEB + writing it back to a different
PEB + erasing the old one is much more expensive than re-reading the
faulty page in raw mode and comparing it to the corrected buffer.
In most cases, the actual number of bitflips does not exceed the
bitflips threshold, and UBI won't have to move data around. Otherwise,
we can assume the time spent re-reading the page and doing the
comparison is negligible compared to the time UBI spends moving a full
PEB to another PEB.

Note that this logic is not applied to chips with 8bits/512byte on-die
ECC, because those chips provide fine-grained information (the maximum
error is 1 bit, and it will not force UBI to move blocks around at the
first bitflip).

Suggested-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
drivers/mtd/nand/raw/nand_micron.c