From: Matthieu CASTET <matthieu.castet@parrot.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mtd: nand: subpage write support for hardware based ECC schemes
Date: Mon, 18 Mar 2013 16:42:13 +0100 [thread overview]
Message-ID: <514735D5.3010105@parrot.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73E9A288C@DBDE01.ent.ti.com>
Gupta, Pekon a écrit :
> Hi,
>
>> On which controller was it tested ?
>
> [Pekon]: I tested it on TI's omap controller itself :-)
> However I ran following, to confirm..
> (1) mtd_subpagetest: part of MTD tests
> (2) ubiattach & ubiformat of ubi image built with Volume Header at 512 offset
> that is using -O 512.
> (3) nand raw read / write with non-page aligned data.
>
> Do you have any other tests in mind ?
>
>
>> The problem is that lot's of controller driver with hw ecc hack the ecc interface.
>
>> For example the TI omap driver don't use the data pointer of ecc.calculate but
>> use the data send on the nand interface.
>
> [Pekon]: Yes i agree. But what I see in TI's hack also that ECC is calculated for
> each subpage separately. Its just that instead of using data in
> chip->buffers->databuf
> TI's driver uses data which is present in controller's internal buffers, which
> should be the way if we are depending on Hardware (controller) to do ECC.
> Is this something different from other Hardware based ECC implementations?
Yes for example some controller have ecc that for a 0xff page is not 0xff.
And this ecc is generated on the fly : you can't xor it before writing it to the
flash.
I know that omap driver with ELM error correction did not generated 0xff ecc for
a black page. I wonder if it works why your patch.
Matthieu
next prev parent reply other threads:[~2013-03-18 15:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 12:59 [PATCH] mtd: nand: subpage write support for hardware based ECC schemes Gupta, Pekon
2013-03-15 13:15 ` Matthieu CASTET
2013-03-15 18:11 ` Gupta, Pekon
2013-03-18 15:42 ` Matthieu CASTET [this message]
2013-03-25 4:17 ` Gupta, Pekon
2013-03-27 8:44 ` Gupta, Pekon
2013-04-04 15:16 ` Artem Bityutskiy
2013-04-05 9:07 ` Gupta, Pekon
2013-04-05 10:43 ` Artem Bityutskiy
2013-04-05 12:56 ` Roland Stigge
2013-04-05 10:44 ` Artem Bityutskiy
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=514735D5.3010105@parrot.com \
--to=matthieu.castet@parrot.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 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.