All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Djelic <ivan.djelic@parrot.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	afzal@ti.com
Subject: Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Date: Wed, 9 May 2012 10:07:47 +0200	[thread overview]
Message-ID: <20120509080747.GB17333@parrot.com> (raw)
In-Reply-To: <20120509002927.GF5088@atomide.com>

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

Note that I could prepare a new MTD patch with BCH ecc code included,
allowing to drop the GPMC BCH ecc api.

BR,
--
Ivan

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

WARNING: multiple messages have this Message-ID (diff)
From: Ivan Djelic <ivan.djelic@parrot.com>
To: Tony Lindgren <tony@atomide.com>
Cc: afzal@ti.com,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes
Date: Wed, 9 May 2012 10:07:47 +0200	[thread overview]
Message-ID: <20120509080747.GB17333@parrot.com> (raw)
In-Reply-To: <20120509002927.GF5088@atomide.com>

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

Note that I could prepare a new MTD patch with BCH ecc code included,
allowing to drop the GPMC BCH ecc api.

BR,
--
Ivan

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

  reply	other threads:[~2012-05-09  8:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26 12:17 [PATCH v3] ARM: OMAP3: gpmc: add BCH ecc api and modes Ivan Djelic
2012-04-26 12:17 ` Ivan Djelic
2012-05-09  0:29 ` Tony Lindgren
2012-05-09  8:07   ` Ivan Djelic [this message]
2012-05-09  8:07     ` Ivan Djelic
2012-05-09  8:10   ` Ivan Djelic
2012-05-09  8:10     ` Ivan Djelic
2012-05-09 15:31     ` Tony Lindgren
2012-05-09 15:31       ` Tony Lindgren
2012-05-10  6:49       ` Mohammed, Afzal
2012-05-10 13:07       ` Artem Bityutskiy
2012-05-10 15:17         ` Ivan Djelic
2012-05-10 15:52           ` Artem Bityutskiy
2012-05-10 17:45             ` Ivan Djelic
2012-05-10 19:02               ` Tony Lindgren
2012-05-10 19:02                 ` Tony Lindgren
2012-05-11 15:38               ` Artem Bityutskiy
2012-05-11 15:50               ` Mohammed, Afzal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120509080747.GB17333@parrot.com \
    --to=ivan.djelic@parrot.com \
    --cc=afzal@ti.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.