From: Brian Norris <computersforpeace@gmail.com>
To: Stefan Agner <stefan@agner.ch>
Cc: dwmw2@infradead.org, sebastian@breakpoint.cc, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
shawn.guo@linaro.org, kernel@pengutronix.de,
boris.brezillon@free-electrons.com, marb@ixxat.de,
aaron@tastycactus.com, bpringlemeir@gmail.com,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, albert.aribaud@3adev.fr,
Bill Pringlemeir <bpringlemeir@nbsps.com>
Subject: Re: [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Fri, 31 Jul 2015 16:47:18 -0700 [thread overview]
Message-ID: <20150731234718.GO10676@google.com> (raw)
In-Reply-To: <9dd7975072cf16dd6ea1947bd4ae830a@agner.ch>
On Sat, Aug 01, 2015 at 01:35:52AM +0200, Stefan Agner wrote:
> On 2015-08-01 01:09, Brian Norris wrote:
> >> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
> >> + uint8_t *buf, int oob_required, int page)
> >> +{
> >> + int eccsize = chip->ecc.size;
> >> + int stat;
> >> +
> >> + vf610_nfc_read_buf(mtd, buf, eccsize);
> >> +
> >> + if (oob_required)
> >> + vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >
> > To fix the bitflips issue above, you'll just want to unconditionally
> > read the OOB (it's fine to ignore 'oob_required') and...
> >
> >> +
> >> + stat = vf610_nfc_correct_data(mtd, buf);
> >
> > ...pass in chip->oob_poi as a third argument.
> >
>
> Hm, this probably will have an effect on performance, since we usually
> omit the OOB if not requested.
You could test :) I don't really like performance claims without tests.
(I say this because I added the oob_required flag myself, but just for
functional purposes, not performance. Many drivers got by just fine by
always copying the OOB data.)
> I could fetch the OOB from the NAND
> controllers SRAM only if necessary (if HW ECC status is not ok...). Does
> this sound reasonable?
That does.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: computersforpeace@gmail.com (Brian Norris)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Fri, 31 Jul 2015 16:47:18 -0700 [thread overview]
Message-ID: <20150731234718.GO10676@google.com> (raw)
In-Reply-To: <9dd7975072cf16dd6ea1947bd4ae830a@agner.ch>
On Sat, Aug 01, 2015 at 01:35:52AM +0200, Stefan Agner wrote:
> On 2015-08-01 01:09, Brian Norris wrote:
> >> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
> >> + uint8_t *buf, int oob_required, int page)
> >> +{
> >> + int eccsize = chip->ecc.size;
> >> + int stat;
> >> +
> >> + vf610_nfc_read_buf(mtd, buf, eccsize);
> >> +
> >> + if (oob_required)
> >> + vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >
> > To fix the bitflips issue above, you'll just want to unconditionally
> > read the OOB (it's fine to ignore 'oob_required') and...
> >
> >> +
> >> + stat = vf610_nfc_correct_data(mtd, buf);
> >
> > ...pass in chip->oob_poi as a third argument.
> >
>
> Hm, this probably will have an effect on performance, since we usually
> omit the OOB if not requested.
You could test :) I don't really like performance claims without tests.
(I say this because I added the oob_required flag myself, but just for
functional purposes, not performance. Many drivers got by just fine by
always copying the OOB data.)
> I could fetch the OOB from the NAND
> controllers SRAM only if necessary (if HW ECC status is not ok...). Does
> this sound reasonable?
That does.
Brian
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
Cc: dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
sebastian-E0PNVn5OA6ohrxcnuTQ+TQ@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pawel.moll-5wv7dgnIgG8@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
marb-Z4QKGCRq86k@public.gmane.org,
aaron-yuhzfaV+M/Wz3Dx2OeFgIA@public.gmane.org,
bpringlemeir-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
albert.aribaud-iEu9NFBzPZE@public.gmane.org,
Bill Pringlemeir
<bpringlemeir-ygJ1pmMJ17cAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Fri, 31 Jul 2015 16:47:18 -0700 [thread overview]
Message-ID: <20150731234718.GO10676@google.com> (raw)
In-Reply-To: <9dd7975072cf16dd6ea1947bd4ae830a-XLVq0VzYD2Y@public.gmane.org>
On Sat, Aug 01, 2015 at 01:35:52AM +0200, Stefan Agner wrote:
> On 2015-08-01 01:09, Brian Norris wrote:
> >> +static int vf610_nfc_read_page(struct mtd_info *mtd, struct nand_chip *chip,
> >> + uint8_t *buf, int oob_required, int page)
> >> +{
> >> + int eccsize = chip->ecc.size;
> >> + int stat;
> >> +
> >> + vf610_nfc_read_buf(mtd, buf, eccsize);
> >> +
> >> + if (oob_required)
> >> + vf610_nfc_read_buf(mtd, chip->oob_poi, mtd->oobsize);
> >
> > To fix the bitflips issue above, you'll just want to unconditionally
> > read the OOB (it's fine to ignore 'oob_required') and...
> >
> >> +
> >> + stat = vf610_nfc_correct_data(mtd, buf);
> >
> > ...pass in chip->oob_poi as a third argument.
> >
>
> Hm, this probably will have an effect on performance, since we usually
> omit the OOB if not requested.
You could test :) I don't really like performance claims without tests.
(I say this because I added the oob_required flag myself, but just for
functional purposes, not performance. Many drivers got by just fine by
always copying the OOB data.)
> I could fetch the OOB from the NAND
> controllers SRAM only if necessary (if HW ECC status is not ok...). Does
> this sound reasonable?
That does.
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-07-31 23:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 16:52 [PATCH v9 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610 Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 16:52 ` [PATCH v9 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 19:40 ` Albert ARIBAUD
2015-07-31 19:40 ` Albert ARIBAUD
2015-07-31 22:56 ` Brian Norris
2015-07-31 22:56 ` Brian Norris
2015-07-31 22:56 ` Brian Norris
2015-07-31 16:52 ` [PATCH v9 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 23:09 ` Brian Norris
2015-07-31 23:09 ` Brian Norris
2015-07-31 23:35 ` Stefan Agner
2015-07-31 23:35 ` Stefan Agner
2015-07-31 23:35 ` Stefan Agner
2015-07-31 23:47 ` Brian Norris [this message]
2015-07-31 23:47 ` Brian Norris
2015-07-31 23:47 ` Brian Norris
2015-08-01 0:28 ` Stefan Agner
2015-08-01 0:28 ` Stefan Agner
2015-08-01 1:50 ` Brian Norris
2015-08-01 1:50 ` Brian Norris
2015-08-01 1:50 ` Brian Norris
2015-07-31 16:52 ` [PATCH v9 3/5] mtd: nand: vf610_nfc: add device tree bindings Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 16:52 ` Stefan Agner
2015-07-31 23:13 ` Stefan Agner
2015-07-31 23:13 ` Stefan Agner
2015-07-31 23:13 ` Stefan Agner
2015-07-31 23:17 ` Brian Norris
2015-07-31 23:17 ` Brian Norris
2015-07-31 23:17 ` Brian Norris
2015-07-31 16:53 ` [PATCH v9 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial Stefan Agner
2015-07-31 16:53 ` Stefan Agner
2015-07-31 16:53 ` Stefan Agner
2015-07-31 16:53 ` [PATCH v9 5/5] ARM: dts: vf-colibri: enable NAND flash controller Stefan Agner
2015-07-31 16:53 ` Stefan Agner
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=20150731234718.GO10676@google.com \
--to=computersforpeace@gmail.com \
--cc=aaron@tastycactus.com \
--cc=albert.aribaud@3adev.fr \
--cc=boris.brezillon@free-electrons.com \
--cc=bpringlemeir@gmail.com \
--cc=bpringlemeir@nbsps.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marb@ixxat.de \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=sebastian@breakpoint.cc \
--cc=shawn.guo@linaro.org \
--cc=stefan@agner.ch \
/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.