From: Stefan Agner <stefan@agner.ch>
To: Brian Norris <computersforpeace@gmail.com>
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,
klimov.linux@gmail.com, Bill Pringlemeir <bpringlemeir@nbsps.com>
Subject: Re: [PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Wed, 07 Oct 2015 16:34:30 -0700 [thread overview]
Message-ID: <0291312bcff1d7a22f7cdee69848dfcb@agner.ch> (raw)
In-Reply-To: <20150929205727.GP31505@google.com>
Hi Brian,
On 2015-09-29 13:57, Brian Norris wrote:
> Pushed this patch to l2-mtd.git, as it looks pretty much good. Although,
> I'd like raw read support...
>
> On Wed, Sep 02, 2015 at 06:06:34PM -0700, Stefan Agner wrote:
>> This adds hardware ECC support using the BCH encoder in the NFC IP.
>> The ECC encoder supports up to 32-bit correction by using 60 error
>> correction bytes. There is no sub-page ECC step, ECC is calculated
>> always accross the whole page (up to 2k pages).
>>
>> Limitations:
>> - HW ECC: Only 2K page with 64+ OOB.
>> - HW ECC: Only 24 and 32-bit error correction implemented.
>>
>> Raw writes have been tested using the generic nand_write_page_raw
>> implementation. However, raw reads are currently not possible
>> because the controller need to know whether we are going to use
>> the ECC mode already at NAND_CMD_READ0 command time. At this point
>> we do not have the information whether it is a raw read or a
>> regular read at driver level...
>
> Hmm, can you get this in ecc.read_page_raw()?
Even just a read_page_raw implementation doesn't help. The controller
requires the ECC to be configured at command issue time, and the driver
issues the command in the cmdfunc callback. The function
nand_do_read_ops calls cmdfunc before ecc.read_page_raw...
I could just bail out in the NAND_CMD_READ0 case, and execute the
command from within the ecc.read_page_raw callback function. A bit
hacky, but that would work.
For that case, it would be nicer if cmdfunc somehow provides the
information that a raw read is requested, we would have that information
in nand_do_read_ops. However, that would need an extension of the
cmdfunc interface... Also, not sure how that should look like.
--
Stefan
WARNING: multiple messages have this Message-ID (diff)
From: stefan@agner.ch (Stefan Agner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Date: Wed, 07 Oct 2015 16:34:30 -0700 [thread overview]
Message-ID: <0291312bcff1d7a22f7cdee69848dfcb@agner.ch> (raw)
In-Reply-To: <20150929205727.GP31505@google.com>
Hi Brian,
On 2015-09-29 13:57, Brian Norris wrote:
> Pushed this patch to l2-mtd.git, as it looks pretty much good. Although,
> I'd like raw read support...
>
> On Wed, Sep 02, 2015 at 06:06:34PM -0700, Stefan Agner wrote:
>> This adds hardware ECC support using the BCH encoder in the NFC IP.
>> The ECC encoder supports up to 32-bit correction by using 60 error
>> correction bytes. There is no sub-page ECC step, ECC is calculated
>> always accross the whole page (up to 2k pages).
>>
>> Limitations:
>> - HW ECC: Only 2K page with 64+ OOB.
>> - HW ECC: Only 24 and 32-bit error correction implemented.
>>
>> Raw writes have been tested using the generic nand_write_page_raw
>> implementation. However, raw reads are currently not possible
>> because the controller need to know whether we are going to use
>> the ECC mode already at NAND_CMD_READ0 command time. At this point
>> we do not have the information whether it is a raw read or a
>> regular read at driver level...
>
> Hmm, can you get this in ecc.read_page_raw()?
Even just a read_page_raw implementation doesn't help. The controller
requires the ECC to be configured at command issue time, and the driver
issues the command in the cmdfunc callback. The function
nand_do_read_ops calls cmdfunc before ecc.read_page_raw...
I could just bail out in the NAND_CMD_READ0 case, and execute the
command from within the ecc.read_page_raw callback function. A bit
hacky, but that would work.
For that case, it would be nicer if cmdfunc somehow provides the
information that a raw read is requested, we would have that information
in nand_do_read_ops. However, that would need an extension of the
cmdfunc interface... Also, not sure how that should look like.
--
Stefan
next prev parent reply other threads:[~2015-10-07 23:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 1:06 [PATCH v12 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610 Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-03 1:06 ` [PATCH v12 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-04 4:10 ` Alexey Klimov
2015-09-04 4:10 ` Alexey Klimov
2015-09-04 4:10 ` Alexey Klimov
2015-09-29 20:55 ` Brian Norris
2015-09-29 20:55 ` Brian Norris
2015-09-03 1:06 ` [PATCH v12 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-29 20:57 ` Brian Norris
2015-09-29 20:57 ` Brian Norris
2015-09-29 20:57 ` Brian Norris
2015-10-07 23:34 ` Stefan Agner [this message]
2015-10-07 23:34 ` Stefan Agner
2015-09-03 1:06 ` [PATCH v12 3/5] mtd: nand: vf610_nfc: add device tree bindings Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-29 20:59 ` Brian Norris
2015-09-29 20:59 ` Brian Norris
2015-09-29 20:59 ` Brian Norris
2015-09-03 1:06 ` [PATCH v12 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-03 1:06 ` Stefan Agner
2015-09-03 1:06 ` [PATCH v12 5/5] ARM: dts: vf-colibri: enable NAND flash controller Stefan Agner
2015-09-03 1:06 ` 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=0291312bcff1d7a22f7cdee69848dfcb@agner.ch \
--to=stefan@agner.ch \
--cc=aaron@tastycactus.com \
--cc=albert.aribaud@3adev.fr \
--cc=boris.brezillon@free-electrons.com \
--cc=bpringlemeir@gmail.com \
--cc=bpringlemeir@nbsps.com \
--cc=computersforpeace@gmail.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=klimov.linux@gmail.com \
--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 \
/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.