* Tony Lindgren <tony@xxxxxxxxxxx> [120425 09:01]: > * Artem Bityutskiy <dedekind1@xxxxxxxxx> [120425 08:48]: > > On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Artem Bityutskiy <dedekind1@xxxxxxxxx> [120425 07:52]: > > > > On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: > > > > > This patch adds a simple BCH ecc computation api, similar to the > > > > > existing Hamming ecc api. It is intended to be used by the MTD layer. > > > > > It implements the following features: > > > > > > > > > > - support 4-bit and 8-bit ecc computation > > > > > - do not protect user bytes in spare area, only data area is protected > > > > > - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs > > > > > > > > > > This last feature is obtained by adding a constant polynomial to > > > > > the hardware computed ecc. It allows to correct bitflips in blank pages > > > > > and is extremely useful to support filesystems such as UBIFS, which expect > > > > > erased pages to contain only 0xFFs. > > > > > > > > > > This api has been tested on an OMAP3630 board. > > > > > > > > > > Signed-off-by: Ivan Djelic <ivan.djelic@xxxxxxxxxx> > > > > > > > > Hi Tony, > > > > > > > > what do you think about merging this patch? This is the enabler for > > > > making UBIFS actually usable on OMAP platforms which use BCH ECC. There > > > > are 2 other MTD patches which depend on this - so I wonder if it is > > > > easier to merge this one via the MTD tree, providing it has your/others' > > > > ack(s). > > > > > > Looks OK to me, however there are other pending GPMC patches to convert > > > it to a platform device device driver. Need to look those closer though. > > > Anyways, it's best that I queue them to avoid merge conflicts. > > > > Sure. > > > > > Do you these for other changes for UBIFS? > > > > Not in UBIFS, but in drivers/mtd/nand/omap2.c - Ivan sent another patch > > which adds BCH support to to omap2.c, was sent to linux-omap, subject > > "[PATCH] mtd: nand: omap: add support for hardware BCH ecc" > > > > > If so, I can set up an immutable > > > branch for GPMC that you can merge in as well. > > > > I guess this would be a good idea, but probably it is better to do this > > when you believe you merged most gpmc patches, so probably closer to the > > final -rc? > > Yes let's wait a week or so as there are also the dmaengine patch for > drivers/mtd/nand/omap2.c that might conflict. So let's get the dmaengine > patches to some branch first. Looking at the gpmc platform driver series, we can't merge those until all the board-*.c files are converted. So let's plan on first making sure the dmaengine changes work, then apply the BCH ecc patches. Regards, Tony -- 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
