On Wed, Dec 05, 2012 at 05:15:52AM +0000, Philip, Avinash wrote: (...) > > First a short reminder of pros and cons of the "constant polynomial addition" > > (let's just call it "CPA") feature: > > > > pros: > > - it elegantly solves all problems related to reading an erased page (no clumsy hack needed) > > - better performance: when a bitflip appears on an erased page (often this is a "sticky" bitflip), > > there is no need to perform a full scan+cleanup of the page each time it is read > > No need for scan + cleanup on each read, as the chances of encountering bit flips in erased page > is less. Also to find bit flips in erased page, compare ecc vector for read erased page against > a standard ecc vector. Presence of bit flips can find by checking the compare results. In case of > mismatch, should go for correction of bit flips in erased page with full scan. Hi Avinash, I explicitly mentioned the condition "when a bitflip appears on an erased page", in which case you _do_ have to do a full scan upon each read, until you erase the block; and then, the bitflip may still be there (this is what I called a "sticky" bitflip). My experience with recent devices (4-bit/8-bit) is that erased pages with a single bitflip are not uncommon. For those pages, there is undeniably a performance penalty compared to CPA. Benchmarks would be needed to quantify the overall performance impact, but I suspect it is small. > > So with this approach, we can nullify the effect of CPA for erased page bit flip handling. Well, not completely. I would happily drop CPA is that were the case. > > > > cons: > > - the ecc vector is not compatible with RBL > > > > RBL compatibility is not necessary in my case, because I'm using the OMAP MLC ROM boot mode. > > Rather than completely removing the CPA feature, I'd like to keep it as an option; it could > > even be used with the ELM module. > > I agree RBL compatibility depends on the user. But with RBL compatibility, there is no sacrifice > of any existing feature. Is it right? > > Also nand driver get simplified with removal of CPA, so that both HW & SW error correction > can go for same ecc calculation. Indeed that would be a simplification. > > > > I'm OK to submit a patch in this direction, but first I'd like to wait for the dust to settle > > on arch/arm/mach-omap2 and mtd/nand/omap2.c with Afzal patches and everything; things have become > > a bit complicated to follow recently :-) > > Afzal's changes are in & are settled now. What about this set: http://lists.infradead.org/pipermail/linux-mtd/2012-October/044337.html I cannot see it in l2-mtd-2.6 ? Or did I miss something ? Thanks, -- Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
