* Ivan Djelic <ivan.djelic@xxxxxxxxxx> [120509 01:15]: > On Wed, May 09, 2012 at 01:29:28AM +0100, Tony Lindgren wrote: > > * Ivan Djelic <ivan.djelic@xxxxxxxxxx> [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 -- 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
