[PATCH v3 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND

Philip, Avinash avinashphilip at ti.com
Wed Dec 5 16:15:52 EST 2012


On Sun, Dec 02, 2012 at 03:20:14, Ivan Djelic wrote:
> On Wed, Nov 28, 2012 at 05:01:30AM +0000, Philip, Avinash wrote:
> (...)
> > 
> > Daniel,
> > 
> > So can you start supporting "bch8-am335xrbl-compatible" and remove usage of
> > is_elm_used in dt. This should come in ecc_opt field.
> > 
> > In omap2 NAND driver, AM335x RBL compatibility is achieved depending on ecc_layout
> > and runtime detection of elm module. So options related to can be
> > 1. bch8-am335xrbl-compatible is enabled and run time detection of
> >    Of elm module passed, RBL compatibility achieved.
> > 2. bch8-am335xrbl-compatible is enabled and run time detection of
> >    of elm module failed, RBL compatibility sacrificed but continue with
> >    software BCH8 error correction. Sacrificing RBL compatibility
> >    because of constant polynomial addition and usage of 14 byte instead of 13 byte.
> > 
> > Ivan,
> > Do you have any plan of removing addition of constant polynomial to ecc data
> > and go for extra byte checking to find erased pages?
> > This way we can start support BCH8 with RBL compatible and kernel
> > Didn't put any restriction of the ecc layout.
> 
> Hello Avinash,
> 
> Sorry about the response delay.
> 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.

So with this approach, we can nullify the effect of CPA for erased page bit flip handling.

> 
> 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.

> 
> 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.

> Also, I think it would be nice to move BCH code out of omap2.c into a separate file.
> What do you think ?

With BCH code you mean, omap3_correct_data_bch()?

I think this can be part of omap2 driver it self as it is ecc correctable method for 
nand driver.

Thanks
Avinash

> 
> BR,
> --
> Ivan
> 



More information about the devicetree-discuss mailing list