[PATCH] ARM: OMAP3: gpmc: add BCH ecc api and modes

[Artem Bityutskiy]

On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote:
> Hi,
> 
> * Artem Bityutskiy <dedekind1 at gmail.com> [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 at parrot.com>
> > 
> > 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?

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120425/d410f4a1/attachment.sig>