From: Brian Norris <computersforpeace@gmail.com>
To: David Mosberger <davidm@egauge.net>
Cc: gsi@denx.de, linux-mtd@lists.infradead.org, pekon@ti.com,
dedekind1@gmail.com
Subject: Re: [PATCH v4 1/5] mtd: nand: Detect Micron flash with on-die ECC (aka "internal ECC") enabled.
Date: Mon, 31 Mar 2014 23:39:58 -0700 [thread overview]
Message-ID: <20140401063958.GA6400@brian-ubuntu> (raw)
In-Reply-To: <1396308537-16013-2-git-send-email-davidm@egauge.net>
On Mon, Mar 31, 2014 at 05:28:53PM -0600, David Mosberger wrote:
> Signed-off-by: David Mosberger <davidm@egauge.net>
> ---
> drivers/mtd/nand/nand_base.c | 27 ++++++++++++++++++++++++---
> include/linux/mtd/nand.h | 4 ++++
> 2 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 09fe1b1..f145f00 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3054,11 +3054,30 @@ static int nand_setup_read_retry_micron(struct mtd_info *mtd, int retry_mode)
> feature);
> }
>
> +static void
Does this really need to be on its own line? It doesn't match the style
of anything else.
> +nand_onfi_detect_micron_on_die_ecc(struct mtd_info *mtd,
> + struct nand_chip *chip)
I'm really not sure why the inconsistent style throughout nand_base on
using both an 'mtd' and a 'chip' parameter (we often assume that
'mtd->priv == chip'). If you need the mtd parameter, let's just pass it
instead of 'chip'.
> +{
> + u8 features[ONFI_SUBFEATURE_PARAM_LEN];
> +
> + if (chip->onfi_get_features(mtd, chip, ONFI_FEATURE_ADDR_ARRAY_OP_MODE,
> + features) < 0)
> + return;
> +
> + if (features[0] & ONFI_FEATURE_ARRAY_OP_MODE_ENABLE_ON_DIE_ECC) {
> + /*
> + * If the chip has on-die ECC enabled, we kind of have
> + * to do the same...
> + */
That's not really true at all, is it? We can simply disable the on-die
ECC and use the provided spare area with a different ECC scheme, can't
we? (e.g., software BCH; or an SoC's HW ECC) In fact, I think disabling
the on-die ECC is a more reasonable default; nand_base is used by many
drivers, most of which provide their own implementations, and many of
which would not be compatible with the implementations you provide. A
system should have to "opt in" somehow to enable this, I think.
Additionally, you need a way to inform the hardware driver that you're
using on-die ECC, so they can make the appropriate choices (to disable
their HW ECC, for instance).
BTW, what driver/controller/SoC are you running this with?
> + pr_info("Using on-die ECC\n");
> + }
> +}
> +
> /*
> * Configure chip properties from Micron vendor-specific ONFI table
> */
> -static void nand_onfi_detect_micron(struct nand_chip *chip,
> - struct nand_onfi_params *p)
> +static void nand_onfi_detect_micron(struct mtd_info *mtd,
> + struct nand_chip *chip, struct nand_onfi_params *p)
Ditto on mtd + chip.
> {
> struct nand_onfi_vendor_micron *micron = (void *)p->vendor;
>
> @@ -3067,6 +3086,8 @@ static void nand_onfi_detect_micron(struct nand_chip *chip,
>
> chip->read_retries = micron->read_retry_options;
> chip->setup_read_retry = nand_setup_read_retry_micron;
> +
> + nand_onfi_detect_micron_on_die_ecc(mtd, chip);
> }
>
> /*
> @@ -3168,7 +3189,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
> }
>
> if (p->jedec_id == NAND_MFR_MICRON)
> - nand_onfi_detect_micron(chip, p);
> + nand_onfi_detect_micron(mtd, chip, p);
>
> return 1;
> }
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2bd6e4e..780ab58 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -225,6 +225,10 @@ struct nand_chip;
> /* Vendor-specific feature address (Micron) */
> #define ONFI_FEATURE_ADDR_READ_RETRY 0x89
>
> +/* Vendor-specific array operation mode (Micron) */
> +#define ONFI_FEATURE_ADDR_ARRAY_OP_MODE 0x90
> +#define ONFI_FEATURE_ARRAY_OP_MODE_ENABLE_ON_DIE_ECC 0x08
> +
> /* ONFI subfeature parameters length */
> #define ONFI_SUBFEATURE_PARAM_LEN 4
>
Brian
next prev parent reply other threads:[~2014-04-01 6:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-31 23:28 [PATCH v4 0/5] mtd: nand: Add on-die ECC support David Mosberger
2014-03-31 23:28 ` [PATCH v4 1/5] mtd: nand: Detect Micron flash with on-die ECC (aka "internal ECC") enabled David Mosberger
2014-04-01 6:39 ` Brian Norris [this message]
2014-04-01 15:26 ` David Mosberger
2014-04-02 7:27 ` Gupta, Pekon
2014-04-02 15:07 ` David Mosberger-Tang
2014-04-02 16:50 ` Gerhard Sittig
2014-04-02 17:02 ` David Mosberger
2014-04-03 7:10 ` Gerhard Sittig
[not found] ` <CALnQHM1VLY=t6CaQtHGtp=enNCCj=Xz_QN7sj20hUCd8ZJjKpA@mail.gmail.com>
2014-04-03 15:26 ` David Mosberger
2014-03-31 23:28 ` [PATCH v4 2/5] mtd: nand: Add NAND_ECC_HW_ON_DIE ECC-mode David Mosberger
2014-04-01 6:02 ` Gupta, Pekon
2014-04-01 15:32 ` David Mosberger
2014-04-01 7:24 ` Brian Norris
2014-04-01 15:41 ` David Mosberger
2014-03-31 23:28 ` [PATCH v4 3/5] mtd: nand: Enable subpage-reads on flashes with on-die ECC enabled David Mosberger
2014-03-31 23:28 ` [PATCH v4 4/5] mtd: nand: Allocate extra buffers needed for on-die ECC controller David Mosberger
2014-04-01 7:28 ` Brian Norris
2014-04-01 7:37 ` Gupta, Pekon
2014-04-01 8:24 ` Brian Norris
2014-03-31 23:28 ` [PATCH v4 5/5] mtd: nand: Improve bitflip detection for on-die ECC scheme David Mosberger
2014-04-01 6:29 ` Gupta, Pekon
2014-04-01 15:51 ` David Mosberger
2014-04-01 17:30 ` Brian Norris
2014-04-01 7:50 ` Brian Norris
[not found] ` <CALnQHM2Afp8LD6MtGQTT5jrcb9xJdYXRGD0TZ_s5GASZsbRZeg@mail.gmail.com>
2014-04-01 17:33 ` Brian Norris
2014-04-01 18:01 ` Brian Norris
2014-04-01 18:13 ` David Mosberger-Tang
2014-04-02 7:57 ` Gupta, Pekon
2014-04-01 8:02 ` [PATCH v4 0/5] mtd: nand: Add on-die ECC support Brian Norris
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=20140401063958.GA6400@brian-ubuntu \
--to=computersforpeace@gmail.com \
--cc=davidm@egauge.net \
--cc=dedekind1@gmail.com \
--cc=gsi@denx.de \
--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 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.