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

[Tony Lindgren]

* Ivan Djelic <ivan.djelic at parrot.com> [120509 01:15]:
> On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote:
> > * Ivan Djelic <ivan.djelic at parrot.com> [120426 05:23]:
> > > Hello,
> > > 
> > > Here is version 3 of this patch after review from Tony Lindgren.
> > > This version adds a separate initialization function mostly to check CPU
> > > compatibility. This check cannot be done in gpmc_enable_hwecc_bch() (which
> > > is meant to be called from mtd function ecc.hwctl) because ecc.hwctl is
> > > not called before the first NAND read access, and it cannot return an error
> > > status.
> > 
> > Thanks applying into devel-gpmc branch.
> 
> OK thanks!
> 
> I still have a question though: there are recent patches from
> Afzal Mohammed that seem to go into the opposite direction, that is
> giving back GPMC register access to the omap2 NAND driver.
> In particular, [PATCH v4 17/39] [1] commit message says:
> 
>   GPMC driver has been modified to fill NAND platform data with GPMC
>   NAND register details. As these registers are accessible in NAND
>   driver itself, configure NAND in GPMC by itself.
> 
> This also includes ecc configuration. My original mtd driver patch indeed had
> ecc handling code inside the driver (not in arch/arm/mach-omap2/gpmc.c).
> 
> So, my question is: which direction are we going to with respect to this
> OMAP GPMC/NAND code separation ?

What Afzal is doing is where we're heading. However, I'm afraid that
may not be quite ready for v3.5 merge window as it needs proper testing
on quite a few platforms to avoid issues with various devices connected
to GPMC.
 
> Note that I could prepare a new MTD patch with BCH ecc code included,
> allowing to drop the GPMC BCH ecc api.

OK, let's do that then. I'll drop this patch and you can coordinate
your patch with Afzal.

Regards,

Tony

 
> [1] http://lists.infradead.org/pipermail/linux-mtd/2012-May/041105.html