Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

On Mon, Aug 10, 2009 at 01:27:56PM -0400, s-paulraj@dal.design.ti.com wrote:
From: Sandeep Paulraj s-paulraj@ti.com
This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND chips. This ECC mode is similar to NAND_ECC_HW, with the exception of read_page API that first reads the OOB area, reads the data in chunks, feeds the ECC from OOB area to the ECC hw engine and perform any correction on the data as per the ECC status reported by the engine.
Is this going to be used by any other NAND controllers? If it's not a particularly common thing, perhaps the DaVinci NAND controller driver should just override the read_page method.
Even if it's shared, the alternative read_page should probably be provided in library form for the controller driver to use if desired. We should move most of the so-called generic NAND stuff in that direction; currently it bloats u-boot even on hardware that doesn't need it.
This patch has been accepted by Andrew Morton and can be found at
http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-new-ecc-mode-e...
That's a testing tree -- it's not actually "accepted" if it's not in the mtd tree (or Linus's).
- case NAND_ECC_HW_OOB_FIRST:
/* Similar to NAND_ECC_HW, but a separate read_page handle */
if (!chip->ecc.calculate || !chip->ecc.correct ||
!chip->ecc.hwctl) {
printk(KERN_WARNING "No ECC functions supplied, "
"Hardware ECC not possible\n");
BUG();
}
if (!chip->ecc.read_page)
chip->ecc.read_page = nand_read_page_hwecc_oob_first;
Would anyone ever use this with read_page non-NULL? It seems like its whole point is to overide that.
-Scott
participants (1)
-
Scott Wood