From: Gerhard Sittig <gsi@denx.de>
To: David Mosberger <davidm@egauge.net>
Cc: Brian Norris <computersforpeace@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Gupta, Pekon" <pekon@ti.com>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [REV3] mtd: nand: Prepare for Micron on-die ECC controller support.
Date: Mon, 31 Mar 2014 21:45:22 +0200 [thread overview]
Message-ID: <20140331194522.GL2775@book.gsilab.sittig.org> (raw)
In-Reply-To: <CALnQHM2whsLcM_4q76Skgjj4oVjgAbofX7iAVBgqZkPOu5UWEQ@mail.gmail.com>
On Mon, 2014-03-31 at 12:33 -0600, David Mosberger wrote:
>
> On Sat, Mar 29, 2014 at 7:16 AM, Gerhard Sittig <gsi@denx.de> wrote:
>
> > so the additional buffers only get allocated when upon
> > identification the on-die-ECC feature already is enabled?
>
> Yes.
>
> > not
> > when it's supported, and might get enabled at any later point in
> > time?
>
> There is no way to switch ECC mode later on, is there?
Isn't there the ONFI SETFEATURE request? And don't you use this
very request to disable and enable chip internal ECC support, to
get the raw (uncorrected) bits after bitflips were detected? So
I understand that there is support to enable this mode at will,
and we already have (or will have) code to do so.
If we consider disabling on-die-ECC support when we find it
enabled and know it's not what the user wants to run, then the
next logical step might be to support enabling this feature if
the user wants it and the chip doesn't have it enabled at this
point in time.
So I guess the buffers should get allocated as soon as the chip
supports on-die-ECC. (While the allocation should only get
introduced in the phase where the raw-read and bitflip count gets
added.)
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
next prev parent reply other threads:[~2014-03-31 19:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-28 16:56 [REV3] mtd: nand: Prepare for Micron on-die ECC controller support David Mosberger
2014-03-29 13:16 ` Gerhard Sittig
2014-03-31 18:33 ` David Mosberger
2014-03-31 19:45 ` Gerhard Sittig [this message]
2014-03-31 20:58 ` David Mosberger
2014-04-01 5:29 ` Gupta, Pekon
2014-04-01 9:33 ` Brian Norris
2014-04-01 9:19 ` Brian Norris
2014-04-01 14:06 ` Gerhard Sittig
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=20140331194522.GL2775@book.gsilab.sittig.org \
--to=gsi@denx.de \
--cc=computersforpeace@gmail.com \
--cc=davidm@egauge.net \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pekon@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox